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ABSTRACT 


This  thesis  is  a  case  study  that  examines  missile  development  and  integration  for  the 
DDG-1000  program.  In  particular,  it  analyzes  various  programmatic  decisions  through 
the  lens  of  systems  engineering  standards,  articles  in  scholarly  journals,  established 
government  acquisition  guidelines,  and  case  studies  of  government  and  commercial 
engineering  projects.  Four  risks  were  identified.  First,  failure  to  establish  top-level 
requirements  that  reflect  DDG-1000  specific  needs  introduces  the  potential  for  the 
missiles  to  fail  performance  or  safety  evaluations.  Second,  late  requirement  changes 
imposed  by  the  government  increase  the  potential  for  costly  rework  and  schedule  delays 
if  integration  issues  surface  during  testing.  Third,  a  “use  as  is”  decision  (meaning  that 
legacy  missile  requirements  were  applied  to  the  DDG-1000  missile  effort)  could  result  in 
an  inadequate  system  architecture  and/or  late  identification  of  system  incompatibilities. 
Finally,  organizational  and  funding  issues  have  hampered  the  establishment  and 
efficiency  of  engineering  change  control  and  integration  management.  The  thesis 
recommends:  that  DOD  acquisitions  continue  to  emphasize  and  enable  rigorous 
application  of  systems  engineering  early  in  the  acquisitions  process;  that  all  programs 
perform  a  thorough  flow-down  of  requirements  even  if  utilizing  legacy  systems;  and  that 
all  funding  for  weapon  development  be  placed  in  the  control  of  the  Program  Executive 
Office  for  Integrated  Warfare  Systems. 
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EXECUTIVE  SUMMARY 


This  thesis  is  a  case  study  that  examined  missile  development  and  integration  for  the 
DDG-1000  program.  It  describes  the  strategic  situation  that  spurred  the  initial  DDG-1000 
concept  and  how  the  program  has  changed  in  size  and  scope  over  time.  It  also  describes 
combat  system  development  for  the  ship,  particularly  the  Dual  Band  Radar  and  the  Joint 
Universal  Weapon  Link  (JUWL),  which  allows  SM-2  and  ESSM  missiles  to  be  employed 
by  the  class.  It  analyzed  various  DDG-1000  programmatic  decisions  through  the  lens  of 
systems  engineering  standards,  articles  in  scholarly  journals,  established  government 
acquisition  guidelines,  and  case  studies  of  government  and  commercial  engineering 
projects. 

DDG-1000  was  an  outgrowth  of  the  “Revolution  in  Military  Affairs”  (RMA) 
philosophy  that  gained  prominence  immediately  following  the  First  Gulf  War.  The  RMA 
specifically  advocated  developing  and  fielding  the  most  technologically  advanced 
systems  possible  so  that  U.S.  and  allied  forces  could  gain  overwhelming  dominance  on 
the  battlefield.  Developing  multiple  such  technologies  and  installing  them  simultaneously 
into  a  new  ship  class  runs  counter  to  the  mindset  that  guided  previous  ship  and  submarine 
advancements.  Historically,  new  combatants  utilized  “tried  and  true”  technologies  in 
most  areas  while  featuring  two  or  three  significant  improvements.  Hence  risk  to  the  new 
class  was  limited.  The  commonality  of  hull,  mechanical  and  electrical  and  combat 
systems  (C/S)  between  the  DD-963,  FFG-7,  CG-47,  and  DDG-51  class  are  an  example  of 
this  approach.  When  successful  systems  were  introduced  and  operationally  tested  (such 
as  gas  turbine  propulsion),  they  were  incorporated  into  future  classes.  Similarly,  C/S 
advancements  could  be  retro-fitted  into  previous  classes  (such  as  CG-47  vertical  launch 
systems  were  retro-fitted  into  the  DD-963  class). 

Conversely,  the  Navy  had  experienced  substantial  problems  in  developing 
multiple  advanced  technologies  for  the  Seawolf  class  submarine.  The  costs  of  the  effort 
were  so  substantial,  in  fact,  that  Congress  truncated  the  program.  The  Air  Force’s  B-2 
bomber  program  encountered  similar  problems  and  met  a  similar  fate.  Nevertheless, 


XV 


DDG-1000  proceeded  with  this  risky  development  strategy.  The  results  were  mueh  the 
same  as  the  B-2  and  Seawolf. 

Missile  development  for  DDG-1000  took  the  opposite  approaeh.  “Legaey” 
missiles  were  designated  for  ineorporation  into  DDG-1000  under  the  assumption  that 
minimal  modifieations  to  the  missiles  would  be  neeessary.  But  this  deeision  may  prove  to 
be  a  mistake  beeause  the  radar  and  eombat  systems  that  will  be  used  to  employ  the 
missiles  are  eompletely  new  and  the  legaey  missiles  may  require  signifieant  ehanges  to 
funetion  with  the  new  systems.  The  interfaees  between  the  missile,  the  eombat  system, 
and  the  radar  are  eritieal  to  aehieving  desired  performanee.  Beeause  the  ship,  eombat 
system,  radar,  and  missile  variants  are  still  in  development,  it  is  not  possible  to  give  an 
unequivoeal  or  eomplete  analysis  of  their  performanee.  However,  we  ean  analyze  the 
effort  in  terms  of  risk  and  lessons  learned  from  prior  ease  studies.  The  analysis  of  missile 
development  eondueted  for  this  thesis  identified  four  main  risks. 

First,  failure  to  establish  top  level  missile  requirements  that  re  fleet  DDG-1000 
speeilie  needs  introdueed  the  potential  for  the  missiles  to  fail  performanee  or  safety 
evaluations.  DDG-1000  has  a  different  mission,  different  operating  environment,  and 
different  threat  set  than  the  platforms  the  SM  and  ESSM  were  designed  to  proteet.  Failure 
to  establish  new  requirements  means  that  there  will  be  no  way  to  truly  assess  the 
performanee  of  the  missiles  in  eomparison  to  their  legaey  version. 

Seeond,  late  requirement  ehanges  imposed  by  the  government  inereased  the 
potential  for  eostly  rework  and  sehedule  delays  if  integration  issues  surfaee  during 
testing.  The  Navy  originally  direeted  the  use  of  the  SM-2  Bloek  III-B  missile  for  DDG- 
1000.  In  2012,  several  years  into  the  projeet,  the  III-B  missile  was  replaeed  with  the 
Bloek  III-A  version.  The  missiles  are  not  identieal  and  their  performanee  differenees 
have  already  prompted  software  ehanges  in  the  radar  and  introduee  additional  risk  that 
other  differenees  will  not  be  eaptured  before  operation  testing. 

Third,  a  “use  as  is”  deeision  regarding  missile  interfaees  was  made  early  in  the 
development  effort.  In  essenee,  the  only  new  requirements  given  to  the  ESSM  and  SM 
missile  design  team  related  to  the  development  of  a  new  ship-to-missile  weapon  link  on  a 
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new  frequency.  All  other  requirements,  such  as  pre-  and  post-launch  interfaces, 
electromagnetic  vulnerability  requirements,  and  so  on,  were  carried  forward  from  the 
legacy  Aegis  variants  of  the  missiles.  This  “use  as  is”  decision  could  result  in  inadequate 
system  architecture,  late  identification  of  system  incompatibilities,  or  both.  It  is  a 
certainty  that  the  mechanical  and  electrical  environment  of  DDG-1000  will  differ  from 
the  DDG-5 1  and  CG-47  classes-it  only  remains  to  be  seen  if  the  differences  have  adverse 
effects  on  missile  performance  or  safety.  Late  identification  of  such  issues  could  result  in 
costly  and  time  consuming  changes  to  missile,  radar,  or  launcher  design. 

Finally,  organizational  and  funding  issues  have  hampered  the  establishment  and 
efficiency  of  engineering  change  control  and  integration  management.  These  are  critical 
efforts  to  support  integration  of  the  JUWL-equipped  missiles  with  the  new  combat 
system,  radar,  and  launcher.  Delays  in  these  processes  make  an  already  challenging 
development  effort  that  much  more  difficult. 

The  thesis  recommends  that  DOD  acquisitions  continue  to  emphasize  and  enable 
rigorous  application  of  system  engineering  principles  early  in  the  acquisitions  process; 
that  all  programs  perform  a  thorough  flow-down  of  requirements  even  if  utilizing  legacy 
systems;  and  that  all  funding  for  weapon  development  be  placed  in  the  control  of  the 
Program  Executive  Office  for  Integrated  Warfare  Systems.  All  of  these  recommendations 
are  based  upon  results  from  prior  development  efforts  as  well  as  systems  engineering 
standards  and  best  practices  from  academia,  industry,  and  government.  In  particular,  the 
critical  importance  of  integration  is  supported  by  Langford’s  Engineering  Systems 
Integration:  Theory,  Metrics  and  Methods  and  KrygieTs  Behind  the  Wizard’s  Curtain: 
An  Integration  Environment  for  a  System  of  Systems  (Langford  2012;  Krygiel  1999). 

Linally,  the  thesis  contends  that  consolidation  of  resources  and  control  over 
systems  engineering  processes  is  supported  by  the  historical  success  of  the  Aegis  combat 
system  and  the  Navy  nuclear  power  program.  Both  efforts  were  afforded  complete 
control  over  all  aspects  of  their  respective  system  designs,  improvements,  training, 
maintenance,  and  support. 
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I.  INTRODUCTION 


A,  BACKGROUND 

The  Department  of  Defense  (DOD)  has  found  it  inereasingly  difficult  to  develop 
and  acquire  advanced  systems  for  military  use  that  meet  cost,  schedule,  and  performance 
goals  (Kadish  2005;  Charette  2008).  The  problem  will  be  even  more  challenging  in  the 
foreseeable  future  as  defense  budget  levels  are  expected  to  remain  stagnant  for  the  next 
decade  (Congressional  Budget  Office  [CBO]  2013). 

The  DOD  has  had  a  long  struggle  with  efficient  system  development  and  both 
identified  causes  and  potential  solutions  have  been  proposed  for  as  long  as  the  DOD  has 
existed  (Kadish  2005).  The  systems  acquired  are  often  based  on  extremely  advanced 
technology,  have  extremely  high  performance  standards,  and  are  expected  to  operate  in 
harsh  environments.  They  are  expected  to  have  long  service  lives  and  to  be  very  reliable, 
easy  to  maintain,  and  easy  to  repair.  Systems  are  also  increasingly  expected  to  be 
interoperable  with  other  new  and  legacy  systems  as  the  DOD  continues  to  pursue  its  “net- 
centric”  paradigm  for  weapons  systems  (Defense  Acquisition  University  [DAU]  2010). 
All  of  these  desired  factors,  but  particularly  the  drive  for  ever-increasing  performance, 
would  naturally  be  expected  to  increase  the  anticipated  cost  and  development  time  for  the 
system. 

However,  there  is  also  an  expectation  of  “affordability”  for  every  system  (Welby 
2013).  Congress  has  cut  or  significantly  curtailed  programs  that  have  extremely  high  per- 
unit  cost  compared  to  previous  versions  of  similar  systems,  despite  improved 
performance.  For  instance,  final  numbers  of  the  B-2  “Stealth”  bomber,  the  Seawolf  class 
submarine,  and  the  F-22  fighter  programs  were  dramatically  reduced  after  it  became 
apparent  that  each  would  have  an  extremely  high  per-unit  cost.  There  are  certainly  other 
factors  that  influenced  Congressional  decision-making  on  these  programs,  including 
perceived  threats,  schedule  delays,  and  so  forth,  but  cost  is  one  of  the  primary  lenses 
through  which  Congress  examines  programs  (Rand  Corporation  2011a). 
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One  of  the  methods  the  DOD  uses  to  attempt  to  save  money  in  aequisition  is  the 
re-use  of  existing  systems,  sub-systems  and  eomponents.  The  Zumwalt-elass  ship 
program,  also  known  as  the  Guided  Missile  Destroyer- 1000  or  DDG-1000  program,  was 
directed  to  use  existing  missiles  in  its  design,  thus  sparing  the  expense  of  developing  an 
all-new  missile.  This  directive  was  believed  to  require  minimal  effort  as  the  missiles 
would  only  need  to  be  modified  to  operate  with  the  new  radar  featured  on  DDG-1000. 
Therefore,  integration  activities  and  associated  funding  have  been  very  limited  in 
comparison  to  “new  development”  programs.  Furthermore,  the  modification  effort  was 
not  organized  according  to  traditional  development  program  guidelines  but  was  instead 
pursued  through  a  contractual  modification  to  an  existing  engineering  support  contract. 
DDG-1000  is  currently  scheduled  to  begin  operational  test  and  evaluation  (OT&E) 
activities  in  2015  (O’Rourke  2013). 

B,  PURPOSE 

The  purpose  of  this  paper  is  to  examine  the  history  of  combat  systems 
development  in  the  DDG-1000  program,  specifically  the  integration  of  legacy  missiles 
with  the  new-development  radars  and  combat  system  of  DDG-1000,  in  order  to  evaluate 
the  validity  of  published  “best  practices”  as  well  as  identify  new  lessons  learned  that  can 
be  utilized  by  future  acquisition  programs. 

C.  RESEARCH  QUESTIONS 

No  DDG-1000  ships  have  been  launched  and  no  missiles  have  been  fired  from  the 
ship.  Therefore,  it  is  problematic  to  discuss  missile  integration  efforts  in  absolute  terms  of 
“success”  or  “failure.”  However,  the  history  of  the  DDG-1000  program  and  the  missile 
integration  effort  in  particular  are  long  enough  to  allow  them  to  be  examined  in  relation 
to  established  government,  industry,  and  academic  standards.  This  thesis  will  address  the 
following  questions:  What  lessons  can  be  learned  from  the  integration  of  legacy  missiles 
with  the  new-development  combat  systems  of  DDG-1000?  Does  missile  integration  on 
DDG-1000  validate  or  reject  integration  “best  practices”  as  described  in  government 
policy  documents,  industry  standards,  and  articles  in  scholarly  journals? 
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D,  BENEFITS 


It  is  hoped  that  the  case  study  presented  in  this  thesis  will  provide  readers  with  a 
relevant  analysis  of  “what  works”  when  integrating  legacy  weapons  systems  into  a  new, 
complex  platform. 

E,  SCOPE  AND  METHODOLOGY 

This  paper  will  address  the  integration  of  legacy  missiles  into  the  new- 
development  combat  systems  of  DDG-1000  via  analysis  following  a  literature  review. 
The  paper  will  address  technical  and  programmatic  decisions  from  the  inception  of  the 
DDG-1000  program  until  now,  and  will  identify  potential  future  risks  based  on  the 
historical  analysis.  Sources  for  the  literature  review  include  program  artifacts  such  as 
acquisition  milestone  reviews,  briefings,  and  risk  assessments;  government  reports 
including  Congressional  testimony  and  Government  Accountability  Office  documents; 
scholarly  articles,  textbooks,  and  theses  on  the  topics  of  acquisition  and  integration; 
defense,  acquisitions,  and  systems  engineering  professional  journals;  and  DOD 
acquisition,  engineering,  and  program  management  guidance  documents. 
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II.  HISTORY  OF  THE  DDG-1000  PROGRAM 


A,  INTRODUCTION 

The  DDG-1000  has  been  one  of  the  Navy’s  most  visible  and  controversial 
development  projects  for  almost  twenty  years.  This  chapter  will  describe  the  strategic  and 
operational  context  in  which  the  program  was  initiated.  It  will  describe  the  key 
operational  and  technical  features  of  DDG-1000  and  will  highlight  key  events  since  the 
program’s  start.  This  chapter  will  also  describe  the  current  state  and  potential  future  for 
DDG-1000,  which  is  far  different  from  its  original  announced  purpose. 

B,  GENESIS  OF  THE  PROGRAM 

The  DDG-1000  program  began  in  1994  (Hagerty  et  al.  2008).  It  was  an  outgrowth 
of  the  “Surface  Combatant  for  the  21st  Century  (SC-21)”  study  the  Navy  conducted  in 
the  early  1990s  (O’Rourke  2013).  Originally  known  as  DD-21,  and  then  DD(X),  it  was 
planned  as  a  significant  class  of  32  warships.  It  was  part  of  a  family  of  three  future 
warship  classes  conceptualized  to  implement  the  Navy’s  post-Cold  War  strategic  vision. 
The  three  proposed  ship  classes  were  the  DD(X),  the  CG(X),  and  the  LCS.  The  new 
strategic  vision,  outlined  in  the  Navy  document  Forward. ..From  the  Sea,  reflected  a 
change  in  emphasis  from  open  ocean  dominance  against  a  peer  adversary  to  power 
projection  and  influencing  events  ashore  (Dalton  1994).  The  three  ship  classes  reflected 
that  shift.  The  DD(X)  would  provide  precision  strike  against  land  targets,  the  CG(X) 
would  provide  advanced  air  and  ballistic  missile  defense,  and  the  LCS  would  provide 
surface  and  antisubmarine  (ASW)  capability  in  the  littorals  (CBO  2003).  The  Navy 
originally  intended  the  new  ship  to  replace  the  FFG-7  and  eventually  the  DDG-5 1  class 
ships,  at  a  per-unit  cost  less  than  that  of  the  DDG-5 1  (Hagerty  et  al.  2008). 

The  new  strategy  was  based  on  the  perceived  lack  of  a  near-peer  adversary 
capable  of  challenging  U.S.  dominance  on  the  open  ocean.  It  also  reflected  a  new  belief 
that  the  technological  dominance  of  U.S.  forces  (demonstrated  during  the  First  Gulf  War) 
would  allow  the  U.S.  to  fundamentally  alter  the  nature  of  warfare.  This  “Revolution  in 
Military  Affairs”  (RMA)  paradigm  dominated  strategic  thinking  in  the  early  to  mid- 
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1990s  and  spurred  a  military  acquisition  philosophy  that  emphasized  acquiring  even  more 
advanced  technologies  (Metz  and  Kievit  1995).  During  the  2000  presidential  campaign, 
then-candidate  George  Bush  gave  speeches  calling  for  the  Pentagon  to  “skip  a  generation 
of  weapons”  in  order  to  achieve  overwhelming  dominance  against  any  potential 
adversary  (Owens  2013). 

The  1993  Defense  Bottom-Up  Review  (BUR;  forerunner  of  the  Quadrennial 
Defense  Review)  was  explicit  in  describing  how  the  U.S.  would  apply  this  technological 
superiority  to  defeating  two  simultaneous  enemies  in  regional  wars  (Aspin  1993).  The 
Middle  East  and  Korean  peninsula  were  specifically  cited  as  potential  hotspots,  and 
significant  discussion  was  given  to  potential  “dangers  to  democracy  and  reform”  in  the 
former  Soviet  Union  and  Eastern  Bloc  (Aspin  1993,  2). 

These  new  systems  would  be  combined  into  a  “net-centric”  architecture.  This 
architecture,  supported  by  equally  advanced  command  and  control  systems,  would  give 
U.S.  forces  an  overwhelming  advantage  against  regional  adversaries.  The  Navy  “vision 
statement”  SeaPower  21  described  this  architecture  in  naval  terms  (Clark  2002).  While 
the  RMA  may  have  fallen  from  the  front  page  of  the  strategic  debate,  it  continues  to 
shape  military  acquisition.  Every  major  new  weapon  system  is  described  in  terms  of  its 
“net-centric”  capabilities  and  its  ability  to  operate  in  a  joint  environment  (DAU  2011). 

DDG-1000  reflected  the  “generation  after  next”  technology  sought  by  the  Navy 
and  the  RMA.  The  ships  would  feature  advanced  land  attack  capabilities,  allowing  them 
to  take  the  place  of  the  recently  retired  Iowa-class  battleships.  The  ships  would  not  only 
launch  Tomahawk  missiles  but  were  also  to  feature  an  advanced  gun  system  firing 
extended  range  projectiles  to  perform  naval  surface  fire  support  (NSES)  missions.  They 
would  also  have  low-observable  characteristics  facilitating  their  operation  in  littoral 
areas.  They  were  to  feature  a  host  of  other  technological  improvements  allowing  for 
expansion  of  capabilities  as  even  newer  technologies  became  available.  Eor  instance,  the 
ship’s  integrated  power  system  was  envisioned  as  powering  lasers,  rail  guns,  or  other 
emerging  technologies.  Einally,  the  ships  were  to  utilize  the  “reduced  manning”  concept, 
automating  previously  manpower-intensive  functions  and  thus  costing  less  to  operate 

than  traditional  warships  (Eiszniansky  2006). 
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There  were  a  total  of  ten  eritieal  teehnologies  (see  Figure  1.  )  identified  in  the 
DDG-1000  program  (Government  Accountability  Office  2004): 

•  Wave-piercing  tumblehome  hull  design 

•  Advanced  Gun  System  (AGS)  and  Long-Range  Land  Attack  Projectile 
(LRLAP) 

•  Integrated  Composite  Deckhouse  and  Apertures 

•  Total  Ship  Computing  Environment  (TSCE) 

•  Dual  Band  Radar  (DBR) 

•  Integrated  Undersea  Warfare  System  (RJWS) 

•  Peripheral  Vertical  Launch  System  (PVLS) 

•  MK  57  Vertical  Launch  System  (VLS) 

•  Automatic  Eire  Suppression  System  (AESS) 

•  Integrated  Power  System  (IPS) 


Transforming  Warfighting:  DDG 1000  Critical  Technologies 


Advanced  Gun  System  (AGS) 

■  Initial  guided  flight  testing  complete 
'  Land-based  testing  complete 


Peripheral  Vertical  Launch 
System  (PVLS)  /  Advanced  VLS 
Two  detonation 
tests  conducted 
Missile  restrained 
firing  testing  complete 


Infrared  Mockups  (IR) 

*  Land-based  suppressor 
testing  complete 
’  At-sea  panel  testing 
complete 


Integrated  Composite 
Deckhouse  &  Apertures  (IDHA) 

•  RCS  testing  complete 

*  Co-site  testing  complete 


Dual  Band  Radar 


*  MFR  land-based 
testing  complete 

•  VSR  final  array 
assembly  complete 


Integrated  Power  System  (IPS) 

*  Component  factory 
testing  complete  || 

*  Critical  Test 
Parameters  (CTPs) 
complete 

Autonomic  Fire  Suppression 

System  (AFSS) 

*  At-sea  weapons  effect  and 
autonomic  hre  suppression 
testing  demonstrated 


ymmpf 


model  testing 


luicii  oiiip  v^uMipuiiiig 

Environment  (TSCE) 

’  Software  Releases 
successfully  codedrSilsd.  arxJ  . 
authorized  by  the  Govsmmeiir~% 


Integrated  Undersea 
Warfare  (lUSW) 

*  At-sea  mine  avoidance 
testing  complete 
'  Automation 
testing  complete 


Eigure  1.  DDG-1000  Critical  Technologies  (from  Liszniansky  2006) 
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This  ambitious  level  of  technologieal  development  in  a  single  hull  was  preeisely 
what  was  ealled  for  by  the  Navy’s  strategie  vision.  However,  it  ran  eounter  to  established 
Navy  shipbuilding  policy  that  limited  technological  advances  to  two  or  three  areas  in  a 
new  ship  design.  The  great  success  of  the  DDG-5 1  class  can  be  attributed,  at  least  in  part, 
to  the  fact  that  it  re-used  almost  every  significant  ship  system  featured  on  the  CG-47  class 
cruiser.  Re-use  of  those  successful  systems  greatly  lowered  the  technological  risk  of  the 
program  (Hagerty  et  al.  2008). 

C.  EVOLUTION  OF  THE  PROGRAM 

The  program  began  in  earnest  in  August  of  1998  as  the  Pentagon  awarded 
contracts  to  two  different  industry  groups  to  begin  work  on  system  concept  designs 
(Defense  Industry  Daily  2013).  Work  was  performed  throughout  1999,  2000,  and  2001. 
The  original  acquisition  plan  included  a  “winner  take  all”  decision  to  select  a  design 
submitted  from  two  industry  teams,  headed  by  Bath  Iron  Works  and  Ingalls  Shipbuilding. 
This  unique  approach  had  never  been  applied  to  a  major  shipbuilding  program  before 
(Office  of  the  Assistant  Secretary  of  Defense  2002). 

New  threats  began  altering  national  priorities  during  the  period  of  initial  design 
work.  Even  before  the  terrorist  attacks  of  September  11th,  2001,  the  Pentagon  and  new 
administration  had  been  working  to  define  a  new  strategic  vision  and  a  more  flexible, 
adaptable  military.  The  2001  Quadrennial  Defense  Review  (QDR)  emphasized  ballistic 
missile  defense,  threats  from  failed  states  and  non-state  actors,  and  the  need  to  transform 
U.S.  forces  to  defeat  such  “asymmetric”  threats  (Office  of  the  Secretary  of  Defense 
(OSD)  2001).  The  RMA  transformation  was  now  presented  as  the  way  to  defeat  such 
asymmetric  threats.  The  terrorist  attacks  of  September  11th  and  the  resulting  occupation 
of  Afghanistan  and  Iraq  marked  a  return  to  low  intensity  and  counter-insurgency  warfare. 
These  experiences  seemed  to  validate  the  QDR’s  emphasis  on  flexibility;  this  type  of 
conflict  was  a  far  cry  from  the  technologically  driven  force-on-force  “Sea  Strike”  that 
had  been  anticipated  in  SeaPower  21.  The  need  for  a  conventional  surface  vessel  armed 
with  lasers  or  rail  guns  seemed  far  down  the  list  of  priorities.  By  December  of  2001,  DD- 
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21  was  officially  cancelled.  The  reasons  eited  ineluded  rising  eost  estimates  and  lagging 
teehnologieal  development  (O’Rourke  2004). 

The  DD-21  was  immediately  replaeed  with  DD(X)  (Defense  Industry  Daily  (DID) 
2013).  In  April  of  2002,  Ingalls  (now  part  of  Northrop  Grumman  Ship  Systems)  won  the 
“winner  take  all”  design  decision  and  was  awarded  a  $2.8  billion  eontraet  for  detailed 
design  of  their  winning  proposal  (DID  2013). 

The  Navy  remained  a  strong  proponent  of  the  program,  eontinuing  to  eite  the  need 
for  the  new  destroyer.  The  proeurement  was  redueed  to  24  ships,  however,  at  whieh  time 
the  planned  CG(X)  vessels  would  be  ready  for  eonstruction.  Both  Navy  and  CBO  eost 
estimates  eontinued  to  rise  as  teehnology  development  lagged  behind  sehedule  (Hagerty 
et  al.  2008). 

By  the  time  the  Navy  revised  its  30-year  shipbuilding  plan  and  presented  it  to 
Congress  in  2005,  DD(X)  had  been  redueed  to  “8-12”  ships  (Hagerty  et  al.  2008,  15). 
This  was  driven  by  the  ever-increasing  eost  estimates  for  the  ships,  whieh  in  turn  were 
driven  by  slow  teehnologieal  development.  The  CBO  estimated  that  the  lead  ship  would 
eost  $3.3  billion  and  have  life  cyele  eosts  nearly  double  that  of  the  DDG-51  elass  (DID 
2013).  Ironieally,  2005  saw  many  of  the  eritieal  teehnologies  pass  signifieant  testing  and 
readiness  milestones,  ineluding  the  Total  Ship  Computing  Environment  (TSCE),  the  Dual 
Band  Radar  (DBR),  the  hull  form,  and  the  Peripheral  Vertieal  Eauneh  System  (PVES). 
The  ship  also  passed  its  initial  flag-level  Critieal  Design  Review  (CDR)  in  September  of 
2005.  The  pereeption  of  yet  another  over  budget  and  behind  schedule  program  was  firmly 
entrenched  in  Congress,  however,  and  scrutiny  of  the  program  continued. 

In  April  of  2006,  the  Navy  announeed  a  new  plan  for  proeuring  seven  DDG-1000 
ships  and  the  PY2007  budget  authorized  eonstruetion  of  the  first  two  vessels  (O’Rourke 
2008).  The  Navy  had  also  eontinued  to  alter  its  fundamental  strategie  vision  to  inelude 
homeland  defense,  eooperation  with  international  partners,  and  provision  of  humanitarian 
assistance  (Roughead  2007).  The  speeifie  mention  of  homeland  defense  signified  the 
inereasing  importanee  of  sea-based  ballistie  missile  defense.  And  although  the 
Cooperative  Strategy  for  Century  Seapower  retained  the  concepts  of  forward 
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presence  and  dominance  in  regional  war,  the  new  emphasis  on  engagement  and  “low- 
level”  operations  continued  to  widen  the  gulf  between  the  new,  large  and  expensive 
DDG-1000  and  the  Navy’s  self-professed  needs.  The  evolving  vision  was  much  more  in 
line  with  the  second  of  the  three  SC-21  vessels,  the  Littoral  Combat  Ship  (LCS)  (a 
program  which  has  had  its  own  share  of  problems).  DDG-1000  was  also  out  of 
consideration  for  performing  the  existing  BMD  mission  (which  fell  to  BMD-capable 
Aegis  platforms)  and  the  future  BMD  mission  (which  were  to  be  fulfilled  by  CG(X)). 

The  Navy’s  justification  for  continuing  the  DDG-1000  stated  that  it  would  serve 
as  a  technological  bridge  to  CG(X).  The  Navy  also  claimed  that  DDG-1000  would  not 
only  be  able  to  perform  its  original  mission  of  littoral  fire  support  but  that  it  was  also 
fully  capable  of  conducting  the  blue  water,  fleet  support  missions  of  the  DDG-5 1 .  This 
line  of  reasoning  may  have  backfired  as  the  argument  opened  the  DDG-1000  up  for  direct 
comparison  directly  to  the  DDG-5 1  in  terms  of  cost,  performance,  sea-keeping,  and  a 
host  of  other  factors.  The  appropriateness  of  such  a  comparison  continues  to  be  a  source 
of  debate  (Miller  2012). 

Cost  estimates  and  criticism  on  Capitol  Hill  continued  to  rise  in  2007  and  2008. 
Navy  estimates  at  per  ship  cost  had  risen  to  $3.3  billion  each  and  some  outside  sources 
estimated  $5  billion  or  more  (Hagerty  et  al.  2008).  Even  with  the  most  optimistic 
estimates,  DDG-1000  was  shaping  up  to  be  the  most  expensive  non-nuclear  surface 
vessel  the  Navy  had  ever  bought.  Skepticism  concerning  some  of  the  ten  critical 
technologies  also  became  pronounced,  including  serious  discussion  about  the  stability  of 
the  new  hull  design  and  the  capability  of  the  ship  to  perform  area  air  defense  and  open- 
ocean  ASW  (DID  2013).  In  2007  and  2008,  Congress  began  openly  challenging  the 
Navy’s  shipbuilding  plans  and  there  were  repeated  calls  to  restart  DDG-5 1  production, 
which  had  ended  in  2005  (DID  2013). 

In  July  of  2008,  Chief  of  Naval  Operations  (CNO)  Gary  Roughead  testified 

before  Congress  that  the  Navy  wanted  to  limit  production  of  DDG-1000  to  just  two  ships 

and  re-start  the  DDG-5 1  production  line  in  order  to  meet  its  future  surface  combatant 

needs  (Hagerty  et  al.  2008).  This  plan  also  entailed  cancellation  of  the  CG(X)  program. 

The  first  five  re-started  DDG-5 1  hulls  would  be  Flight  IIA  types;  production  would  then 
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shift  to  a  Flight  III  design  which  would  be  developed  to  meet  the  BMD  mission.  This 
complete  reversal  in  policy  was  a  shocking  turnaround  given  how  strongly  Navy 
leadership  had  defended  the  program  in  the  past.  The  reasons  for  this  change  were 
numerous  but  are  perhaps  best  captured  in  these  two  statements  by  the  CNO: 

While  there  are  cost  savings  associated  with  the  DDG  lOOO's  smaller 
crew,  they  are  largely  offset  by  higher  estimated  maintenance  costs  for  this 
significantly  more  complex  ship.  Clearly  the  relative  value  of  the  DDG 
1000  resides  in  the  combat  system  (Dual-Band  Radar,  Volume  Search 
Radar,  ASW  Suite,  etc.)  that  provide  this  ship  with  superior  warfighting 
capability  in  the  littoral.  However,  the  DDG  51  can  provide  Ballistic 
Missile  Defense  capability  against  short  and  medium  range  ballistic 
missiles  and  area  Anti-Air  Warfare  capability  (required  in  an  anti-access 
environment)  where  the  DDG  1000  currently  does  not.  Upgrading  the 
DDG  1000  combat  system  with  this  capability  would  incur  additional  cost. 

The  DDG  51  class  also  possesses  better  capability  in  active  open  ocean 
anti-Submarine  Warfare  than  does  the  DDG  1000.  On  balance,  the 
procurement  cost  of  a  single  DDG  51  is  significantly  less  than  that  of  a 
DDG  1000,  and  the  life-cycle  costs  of  the  two  classes  are  similar. 
(Roughead,  quoted  in  DID  2013) 

I  started  looking  at  the  DDG- 1000.  It  has  a  lot  of  technology,  but  it  cannot 
perform  broader,  integrated  air  and  missile  defense...  Submarines  can  get 
very  close  [due  to  design  compromises],  and  it  does  not  have  the  ability  to 
take  on  that  threat...  And  I  look  at  the  world  and  I  see  proliferation  of 
missiles,  I  see  proliferation  of  submarines.  And  that  is  what  we  have  to 
deal  with.  (Roughead,  quoted  in  DID  2013) 

A  third  DDG- 1 000  was  eventually  authorized  in  the  FY2009  Defense  Budget 
Authorization,  although  the  Navy  was  given  the  ability  to  transfer  the  funding 
($2.5  billion)  to  DDG-51  construction  if  it  chose  to  do  so.  The  third  DDG- 1000  was 
primarily  a  Congressional  move  to  support  the  shipyards  in  Bath,  Maine,  and  Pascagoula, 
Mississippi. 

The  decision  to  end  the  DDG- 1000  program  after  three  ships  obviously  had 
significant  consequences.  First,  the  decision  resulted  in  a  Nunn-McCurdy  breach  for  the 
program,  formally  reported  to  Congress  in  April  2010.  The  Nunn-McCurdy  provisions 
were  first  included  in  the  1982  Defense  Budget  Authorization  Act  and  were  subsequently 
enacted  into  the  U.S.  code  (Rand  Corporation  2011).  They  call  for  any  defense 
acquisition  program  to  be  reviewed  or  presumptively  cancelled  if  the  program  exceeds 
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cost  estimates  by  eertain  pereentages.  In  order  to  avoid  the  presumptive  caneellation,  the 
aequisition  authority  for  the  program  must  provide  eertifieation  of  certain  eriteria  for  the 
program  to  Congress.  These  eriteria  inelude: 

•  The  program  is  essential  for  national  security 

•  No  alternatives  will  provide  an  aceeptable  eapability  to  meet  requirements 
and  that  new  estimated  of  PAUC  and  APUC  have  been  determined  to  be 
reasonable  by  CAPE 

•  The  program  has  a  higher  priority  than  the  programs  whose  funding  must 
be  redueed  to  aeeommodate  the  “breaehing”  program 

•  The  management  strueture  of  the  program  is  adequate  to  manage  and 
control  PAUC  or  APUC  (Rand  Corporation  2011,  20) 

The  provisions  examine  two  basie  measures  of  program  eost.  PAUC  is  the  total 
development  and  proeurement  eost  divided  by  the  number  of  items  procured.  APUC  is 
the  total  procurement  eost  divided  by  the  number  of  items  proeured.  The  triggers 
assoeiated  with  Nunn-MeCurdy  are  summarized  in  Table  1 .  : 


Table  1.  Nunn-MeCurdy  Provisions  (from  Rand  Corporation  2011,  15) 


Breach  Type 

Measure  examined 

Baseline 

Trigger  Level 

PAUC 

Current 

>  15% 

Signifieant 

APUC 

Current 

>  15% 

PAUC 

Original 

>  30% 

APUC 

Original 

>  30% 

PAUC 

Current 

>  25% 

Critieal 

APUC 

Current 

>  25% 

PAUC 

Original 

>  50% 

APUC 

Original 

>  50% 

The  redueed  quantity  of  ships  resulted  in  a  new  PAUC  of  $5.8  billion,  up  from 
$3.1  billion  that  had  been  estimated  at  the  2005  program  baseline.  A  root  eause  analysis 
was  eompleted  by  the  Offiee  of  the  Seeretary  of  Defense’s  (OSD)  Performanee 
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Assessments  &  Root  Cause  Analysis  (PARCA)  office  to  determine  reasons  for  the 
overrun.  The  main  driver  was,  as  expected,  the  reduction  in  quantity  of  ships.  PAUC  and 
APUC  are  very  sensitive  to  quantity  fluctuations.  However,  PARCA  also  identified  other 
factors  contributing  to  DDG-lOOO’s  enormous  cost  growth.  The  results  are  summarized 
in  Table  2.  : 


Table  2.  DDG-1000  Cost  Growth  Root  Causes  (from  Rand  Corporation  2011,  25) 


Acquisition  phase/activity 

Cost  growth  root  cause 

Baseline  determination 

Unrealistic  estimate 

Immature  technology;  excessive  manufacturing  and 
integration  risk 

Unrealistic  performance  expectations 

Program  execution 

Changes  in  procurement  quantity 

Funding  instability 

Unanticipated  technical  issues 

The  PARCA  analysis,  much  like  a  2009  GAO  report,  highlighted  continuing 
concerns  about  technology  maturity  on  some  of  the  ship’s  critical  systems.  It  warned  that 
since  the  first  hull  had  just  begin  construction,  and  many  of  the  technologies  would  not  be 
certified  until  after  installation,  the  program  was  accepting  a  high  risk  of  potential  re¬ 
work  or  even  design  changes.  In  particular,  the  GAO  cited  the  TSCE  and  the  VSR  radar 
as  “immature”  and  several  years  behind  schedule  (GAO  2009). 

In  June  of  2010,  the  Navy  announced  that  the  VSR  portion  of  the  DBR  would  be 
removed  from  the  ship  design  (DID  2013).  The  removal  of  VSR  was  a  cost/benefit 
decision,  saving  approximately  $100  million  for  each  hull.  It  also  required  modifications 
to  the  MFR  radar,  allowing  it  to  perform  some  search  functions.  The  decision  was  also 
influenced  by  the  development  of  the  AMDR,  the  next  generation  ballistic  missile 
defense  radar  which  was  intended  for  the  future  Flight  III  DDG-5I  (Miller  2012).  Rising 
costs  and  limited  space  on  the  DDG-5 1  hull  for  the  new  AMDR  meant  that  “retro-fitting” 
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AMDR  into  the  DDG-1000,  as  well  as  the  possibility  of  inereasing  the  DDG-1000 
procurement  and  modifying  it  into  the  next  generation  of  BMD  ship  (instead  of  building 
DDG-51  Flight  III),  became  real  possibilities.  These  issues  will  be  discussed  in  greater 
detail  in  Chapter  III  on  combat  systems  development. 

Finally,  the  Navy  recently  began  investigating  the  potential  of  using  regular  steel, 
instead  of  advanced  composites,  to  construct  the  deckhouse  for  DDG-1002  (Fahey  2013). 
This  is  another  cost  saving  move  which  the  Navy  claims  will  not  affect  the  “stealth” 
characteristics  of  the  ship.  The  composite  materials  have  been  a  challenge  for  both 
shipyards  involved  in  DDG-1000  construction. 

D,  CURRENT  STATUS 

The  DDG-1000  program  is  no  longer  the  centerpiece  of  the  future  Navy.  The 
original  procurement  of  32  ships  has  been  reduced  to  just  three.  A  program  once  touted  as 
the  future  of  the  Navy  is  now  essentially  advertised  as  a  test-bed  for  technologies  that 
will  be  installed  on  other  combatants  (Miller  2012).  Costs,  as  predicted  by  various 
agencies  since  the  start  of  the  program,  have  greatly  exceeded  estimates  and  are 
summarized  in  Table  3.  : 


Table  3.  DDG-1000  Cost  Growth  Summary  (from  GAO  2013,  55) 


Measure 

1998  Baseline 

Aug  2012 

%  change 

Total  ships 

32 

3 

-  90% 

Total  cost 

$34.8 

$21.5 

-  38% 

Research  &  Development  Cost 

$2.3 

$10.3 

+  353% 

Procurement  Cost 

$32.5 

$11.1 

-  65% 

Per  ship  cost:  APUC 

$1.0 

$7.2 

+  543% 

PAUC  (without  R&D) 

$1.0 

$3.7 

+  248% 

Total  acquisition  time  (in  months) 

128 

111 

+  73% 

all  $  in  billions 
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As  of  March  2013,  DDG-lOOO’s  hull  is  approximately  82%  complete.  DDG-1001 
is  approximately  52%  eomplete,  and  DDG-1002  has  begun  (Zumwalt  Program  Office 
2013).  Most  of  the  eritieal  technologies  will  not  have  been  demonstrated  until  after  their 
installation  in  the  hull,  a  point  of  teehnical  risk  that  has  been  raised  since  2004  (GAO 
2013).  The  program  is  plaeing  a  great  deal  of  faith  in  its  Engineering  Development 
Model  (EDM)  risk  mitigation  strategy.  The  strategy  ealls  for  EDMs  to  be  built  and  tested 
for  all  eritieal  technologies  so  that  signifieant  issues  ean  be  diseovered  earlier  in  the 
design  and  development  phase  of  the  program.  DDG-1000  is  seheduled  to  be  delivered  to 
the  Navy  in  2014  with  a  signifieant  OT&E  period  to  follow. 

In  eonsidering  the  program  as  a  whole,  one  ean  only  eonelude  that  the  Navy  has 
yet  to  learn  the  lessons  of  previous  major  aequisition  programs.  When  per  unit  eosts 
beeome  exeessive.  Congress  will  simply  balk  at  the  expense,  regardless  of  teehnologieal 
advances.  The  desire  for  technological  advancement  inevitably  leads  to  sehedule  delays, 
whieh  in  turn  means  that  the  strategie  and  operational  needs  of  the  serviee  may  have 
ehanged  in  the  interim.  This  affeeted  DDG-1000  partieularly  hard,  as  the  eoneept  of  a 
land-attack  ship  was  new  to  the  Navy  anyway. 

The  DDG-1000  now  enters  the  same  territory  as  the  B-2  bomber,  the  E-22  fighter, 
and  the  Seawolf  submarine:  a  platform  with  potentially  enormous  eapabilities  that  the 
nation  has  decided  is  too  expensive  to  build  and  operate.  While  aeknowledging  the  faet 
that  rising  DDG-51  Elight  111  eosts  may  still  allow  the  DDG-1000  to  re-enter  the 
eonversation  as  a  possible  future  BMD  platform,  the  ship’s  main  legaey  will  likely  hinge 
upon  how  many  of  her  transformational  teehnologies  beeome  mainstays  for  other  ships. 
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III.  DDG-1000  COMBAT  SYSTEM  DEVELOPMENT  HISTORY 


A,  INTRODUCTION 

One  of  the  hallmarks  of  the  DDG-1000  program  has  been  the  stated  intent  to 
develop  and  field  the  most  eutting-edge  technologies  possible  for  naval  warfare. 
Advanced  technologies  were  to  be  implemented  in  every  area  of  the  ship,  from  the 
material  used  to  build  the  deckhouse  to  the  method  of  providing  main  propulsion.  There 
were  a  total  of  ten  critical  technologies  identified  in  the  program  (GAO  2013).  Combat 
systems  advancements  were  the  leading  features  of  the  program,  but  challenges  in 
developing  these  technologies  have  given  rise  to  criticism  of  DDG-1000  for  both 
effectiveness  and  cost-effectiveness  (Miller  2012).  This  chapter  will  briefly  outline  the 
history  of  combat  systems  in  the  program.  Primary  attention  will  be  given  to  the  DBR 
because  it  is  the  primary  item  that  must  integrate  with  missiles,  although  the  launcher  will 
also  be  examined. 

B,  THE  ADVANCED  GUN  SYSTEM  AND  LONG-RANGE  LAND  ATTACK 

PROJECTILE 

In  one  sense,  the  Advanced  Gun  System  (AGS)  and  Long-Range  Land  Attack 
Projectile  (LRLAP)  are  the  raison  d’  etre  for  the  entire  DDG-1000  program.  As 
described  in  Chapter  II,  precision  land  attack  and  Naval  Surface  Fire  Support  (NSFS)  are 
the  primary  mission  of  the  class.  The  advent  of  the  Tomahawk  cruise  missile  had  made 
the  surface  Navy  relevant  again  for  strategic  and  pre-emptive  strikes  against  enemy 
targets.  However,  the  final  retirement  of  the  Iowa-class  battleships  in  the  mid-1990s 
meant  that  the  Navy’s  traditional  role  of  providing  tactical  fire  support  to  troops  ashore 
was  limited  to  the  5-inch  guns  of  the  DD-963,  CG-47  and  DDG-51  classes.  Many  in 
Navy  and  Marine  circles  felt  the  weapons  were  simply  inadequate  for  the  task,  having 
limited  range  and  firepower  (Welch  2007). 

However,  even  with  the  relative  deficiencies  of  current  5 -inch  guns  compared  to 
the  Navy’s  retired  8-  and  16-inch  guns,  the  benefits  of  naval  gunfire  for  the  NSFS 
mission  are  still  pronounced.  Ships  can  provide  a  constant  volume  of  firepower  in 
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contrast  to  air-delivered  support  (whieh  has  a  cycle  time).  Gunfire  is  also  vastly  less 
expensive  per  shot  than  a  cruise  missile  or  air-delivered  ordnance. 

The  AGS  system  was  intended  to  overeome  the  deficiencies  of  the  Navy’s  5-inch 
gun  system.  It  is  a  6.1-ineh  (155mm)  gun  system  with  a  fully-automated  ammunition 
handling  and  loading  system.  It  will  meet  extended  range  requirements  by  utilizing  the 
roeket-assisted  and  precision-guided  LRLAP  round.  It  will  also  be  capable  of  firing 
conventional  (unguided)  155mm  rounds  (DID  2013).  The  weapon’s  magazines  will  hold 
approximately  600  rounds  (O’Rourke  2013). 

Technieal  risks  and  delays  with  the  system  have  revolved  primarily  around  the 
rounds  themselves.  The  Extended  Range  Guided  Munition  (ERGM)  program  was  a 
twelve-year,  $600  million  failed  effort  to  develop  an  extended  range  round  to  be  fired 
from  the  existing  5-inch/54  gun  system  (Matthews  2008).  The  primary  challenge  is 
developing  internal  guidance  eomponents  that  can  withstand  the  shock  of  being  fired 
from  an  artillery  piece.  ERLAP  also  had  to  redesign  its  roeket  booster,  although  earlier 
tests  had  met  range  requirements.  The  program  had  a  successful  flight  test  of  its 
redesigned  round  in  early  2013  and  contracts  are  now  in  place  to  install  AGS  in  all  three 
DDG-1000  hulls  (DID  2013).  Concerns  about  limited  magazine  eapacities  on  the  ships 
remain,  but  the  AGS  and  ERLAP  are  expected  to  meet  the  requirements  set  for  them. 
Whether  or  not  those  requirements  meet  the  needs  of  the  Navy  will  not  be  known  until 
the  ship  is  employed. 

C.  MK57  VERTICAL  LAUNCHER  SYSTEM  AND  PERIPHERAL 

VERTICAL  LAUNCH  SYSTEM 

DDG-1000  features  two  improvements  in  missile  launeher  design  when  eompared 
to  the  current  mainstay  of  the  Navy:  the  MK41  vertical  launcher  system  (VLS)  installed 
on  the  CG-47  and  DDG-5 1  classes  (and  multiple  allied  ship  classes). 

The  first  improvement  is  the  MK57  launcher  itself.  The  launcher’s  cells  are  larger 
than  the  MK41,  allowing  it  to  earry  all  eurrent  VLS  weapons  and  aecommodate  future 
weapons  that  could  feature  inereases  in  length,  weight,  and  diameter.  It  features  an  open 
architeeture  design,  whieh  should  minimize  the  amount  of  modification  required  to 
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accommodate  those  future  weapons.  In  particular,  the  canister  electronic  unit  (CEU)  will 
serve  as  an  interchangeable  interface  between  weapon  and  launcher,  eliminating  the  need 
to  otherwise  permanently  modify  launcher  hardware  or  software  to  accept  a  partieular 
weapon.  Thus,  the  system  should  meet  the  Navy’s  desired  “any  missile,  any  cell”  design 
(Raytheon  2013).  The  ship’s  combat  system  would  still  need  to  be  modified  to  ensure 
that  it  eould  eommunicate  with  the  new  weapon  via  the  CEU.  These  modifications  are 
presumed  to  be  software  adjustments  only.  Einally,  the  launcher’s  gas  management 
system  is  also  designed  to  aecommodate  future  weapons  and  their  expected  increases  in 
rocket  motor  exhaust  mass  and  flow  rate  (Raytheon  2013). 

The  second  innovation  on  DDG-1000  is  the  introduction  of  the  peripheral  vertical 
launch  system  (PVES).  Although  sometimes  confused  in  the  literature  with  the  Mk57 
launcher  itself,  the  PVES  denotes  the  arrangement  of  the  MK57s  throughout  DDG- 
lOOO’s  hull  and  their  protection  by  a  new  armored  enclosure  (DID  2013).  There  are  20 
groups  of  four  missile  cells  each  distributed  outboard  on  the  hull.  The  armored  enclosures 
are  designed  to  funnel  explosive  energy  out  and  away  from  the  ship’s  hull  during  combat, 
thus  protecting  the  internal  spaces  of  the  ship  as  well  as  adjaeent  launeher  cells.  The 
current  Mk41  VLS  is  a  single  “bloe”  of  eells,  eenterline  on  the  CG-47  and  DDG-51.  A 
single  hit  on  the  Mk41  in  eombat  eould  cause  the  entire  launcher  to  be  inoperable,  thus 
depriving  the  ship  of  its  primary  AAW  armament. 

Eike  almost  all  new  technologies  on  the  DDG-1000,  the  Mk57/PVES  eneountered 
some  teehnical  ehallenges  and  sehedule  delays.  The  new  launcher  has  not,  however,  been 
a  signifieant  programmatic  or  technical  risk  to  date  (DID  2013). 

D,  DUAL  BAND  RADAR 

1.  Brief  Description  of  Current  Radars 

Before  describing  the  development  of  the  DBR  for  DDG-1000,  it  may  be  helpful 
to  briefly  review  the  operation  of  a  typieal  mierowave  radar  and  highlight  the 
eharaeteristies  of  radar  systems  that  use  conventional  antennas  and  those  using  phased 
arrays. 
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Figure  2.  shows  a  generic  microwave  radar  and  its  main  components. 


Figure  2.  Generic  microwave  radar  (from  Harney  2005,  87) 

In  the  most  general  sense,  a  radar  system  generates  electromagnetic  radiation  and 
transmits  it  into  the  atmosphere.  The  radiation  scatters  when  encountering  objects;  the 
scattered  signal  that  returns  to  the  radar  antenna  can  be  evaluated  to  determine  the 
bearing  and  range  to  the  object.  Repeated  transmissions  and  returns  can  be  analyzed  to 
extrapolate  the  object’s  speed  and  direction  of  travel  (Naval  Education  and  Training 
Command  (NETC)  2000). 

All  radars  use  some  form  of  antenna  to  focus  the  transmitted  signal  in  a  certain 
direction  of  travel  and  into  a  certain  beam  form.  It  is  by  using  this  directionality  and 
focus  as  a  reference  point  (as  well  as  known  constants  for  signal  speed)  that  the 
radar  system  assesses  the  returned  signal  to  give  useful  information  to  the  radar  operator. 
A  “traditional”  microwave  radar  uses  some  form  of  a  parabolic  dish  to  focus  the 
transmitted  energy  of  the  radar  (see  Eigure  3.  for  common  types).  This  dish  is 
mechanically  moved  through  the  desired  field  of  regard  by  a  series  of  motors  and 
gimbals.  Eor  instance,  an  air-search  radar  will  typically  spin  360  degrees  to  search  the 
most  volume  of  air  space  possible  around  the  radar  set  itself.  A  monostatic  radar  uses  the 
same  antenna  to  transmit  and  receive  the  RE  energy.  A  duplexer  controls  the  timing  and 
channeling  of  the  sent  and  received  signals  so  that  there  is  no  interference  internal  to  the 
system.  A  bistatic  radar  uses  a  separate  dish  for  sent  and  received  signals.  The  two 

antennas  are  usually  in  close  physical  proximity  to  each  other  (Harney  2005). 
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Figure  3.  Common  Reflective  Antenna  Shapes  (from  Skolnick  2008,  560) 

Variations  in  the  characteristics  of  the  radar  (frequency/wavelength,  amount  of 
power  generated  by  the  radar,  rate  of  antenna  spin,  etc.)  result  in  performance 
differences.  Those  performance  differences  are  maximized  depending  on  the  intended 
function  of  the  radar.  As  mentioned,  air  search  radars  typically  cover  a  360  field  and  are 
designed  to  transmit  energy  into  the  widest  area  possible.  They  can  have  detection  ranges 
in  excess  of  200  nautical  miles  (NETC  2000).  A  missile  director,  on  the  other  hand, 
typically  features  a  very  narrow  beam  that  is  steered  only  the  amount  necessary  to  keep 
its  target  within  the  director’s  beam. 

In  the  naval  environment,  radars  have  been  optimized  for  surface  detection  and 
tracking,  gunfire  support,  air  search  and  tracking,  missile  guidance,  and  so  on  (NETC 
2000).  Search  and  track  radars  are  typically  “pulsed”  beam  forms,  meaning  that  the  RE 
energy  is  emitted  in  pulses.  During  the  non-transmitting  period  of  time  the  radar  receives 
and  processes  the  return  from  the  target.  The  more  rapidly  the  radar  “pulses”  its  signal  the 
more  rapidly  it  can  update  its  target  information.  However,  high  pulse  repetition  rates 
(PRR)  reduce  the  effective  range  of  the  radar.  Illumination  radars  are  often  have 
extremely  high  PRR  or  are  of  the  continuous  wave  type  because  intercepting  a  fast  target 
requires  the  most  accurate  target  position  possible.  Continuous  wave  illuminators  utilize 
the  frequency  shift  between  its  own  signal  and  the  target  return  signal  (the  Doppler  shift) 
to  determine  target  range,  etc.  They  are  often  of  the  bistatic  type-the  NATO  SeaSparrow 
missile  system  is  a  good  example  (NETC  2000). 
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It  is  important  to  note  that  missile  engagement  systems  that  utilize  eontinuous 
wave  illumination  require  the  missile  to  have  a  reeeiver  onboard  the  missile  to  reeeive  the 
refleeted  energy  from  the  target,  a  processor  to  calculate  target  position  in  relation  to  the 
missile’s  own  position,  and  an  autopilot  which  will  command  the  missile  to  maneuver  to 
intercept  the  target.  The  illuminator  uses  the  reflected  energy  to  calculate  a  pointing 
position  to  maintain  its  beam  on  the  target  (NETC  2000).  When  used  in  an  environment 
where  targets  are  travelling  at  high  subsonic  or  supersonic  speeds  and  have  a  small  radar 
cross-section,  it  becomes  clear  that  these  calculations  and  updates  must  be  performed  as 
rapidly  as  possible. 

While  traditional  antenna  systems  are  a  very  capable  and  mature  technology,  they 
do  have  significant  drawbacks.  First,  the  mechanical  systems  required  to  allow  the  RE 
energy  to  be  coupled  into  the  moving  antenna  are  complex  and  prone  to  failure  (or  are,  at 
least,  maintenance-intensive).  Second,  the  varying  characteristics  needed  for  different 
applications  are  implemented  primarily  via  the  physical  and  mechanical  characteristics  of 
the  radar;  which  meant  that  ships  needed  a  multitude  of  independent  radar  systems  to 
accomplish  their  varying  missions.  As  mentioned,  the  frequency  and  pulse  width  of  the 
radar,  which  greatly  determine  its  range  resolution,  are  fixed  by  its  electronic  and 
mechanical  properties,  as  are  its  maximum  effective  range,  performance  against  certain 
size  targets,  and  so  on  (O’Donnell  2010;  NETC  2000). 

Consider  the  DD-963  class  destroyers,  which  entered  the  fleet  in  the  mid-1970s. 
By  the  early  2000s,  the  ships  had  a  wide  variety  of  radar  systems  installed  as  listed  in 
Table  4.  . 


22 


Table  4.  DD-963  class  installed  radars 


Radar 

Function 

SPS-40 

Air  search 

SPS-55 

Surface  search 

SPS-64 

Surface  search 

Furuno 

Commercial  surface  search  radar, 
used  for  navigation  support 

SPG-60 

Air  target  fire  control  for  MK86 
gunfire  control  system  (5”  guns) 

SPQ-9 

Surface  target  for  control  for  MK86 
gunfire  control  system  (5”  guns) 

MK23  TAS  (Target 
Acquisition  System) 

Air  search  radar  for  the  SeaSparrow 
weapon  system 

MK95 

Fire  control  director  for  SeaSparrow 
weapon  system 

MK15  Phalanx 

Two  radars  (search  and  track)  to 
support  the  MK15  Phalanx  CIWS 
(Close  In  Weapon  System) 

Each  of  these  systems  requires  maintenance  and  upkeep,  specific  training  for  both 
operation  and  maintenance,  spare  part  support  (which  entails  a  logistic  support  system), 
and  so  on.  The  complexity  of  the  systems  removes  the  possibility  of  cross-training  sailors 
to  operate  and  maintain  more  than  one  system;  indeed  the  Navy  has  multiple  ratings  of 
sailors  to  perform  those  functions. 

A  phased-array  radar  introduces  a  new  approach  to  implementing  radar  antenna 
functionality.  The  antenna  is  a  fiat  panel  of  multiple  emitting  elements.  The  radar  signal 
can  be  adjusted  (via  phase  timing)  so  that  each  module  emits  its  signal  to  produce  a 
coherent  radar  beam  in  a  desired  direction  (as  seen  in  Figure  4.  ).  This  greatly  improves 
performance.  It  increases  the  speed  with  which  the  radar  can  scan  its  field  of  view  and  it 
eliminates  the  complex  mechanical  systems  required  for  a  moving  antenna  (NETC  2000). 
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The  time  required  for  a  meehanieally-seanned  radar  to  move  its  field  of  view  20  degrees 
is  measured  in  seconds.  A  phased  array  can  perform  the  same  re-direction  in 
microseconds  (O’Donnell  2010).  This  enormous  improvement,  coupled  with  the  power  of 
modem  computers  to  process  returned  signals,  results  in  dramatic  performance 
improvements.  The  radar  can  produce  extremely  accurate  information  about  the  contacts 
it  is  tracking.  Recall  the  earlier  discussion  of  the  necessity  of  accurate  information  when 
attempting  to  accurately  track  and  intercept  high  speed  targets. 
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Figure  4.  Formation  of  radar  wave  by  phased  array  (from  O’Donnell  2010,  8) 


The  phased  antenna  also  allows  the  radar  to  form  multiple  beams  by  selectively 
controlling  the  timing  and  phase  of  the  elements,  which  in  turn  allows  the  radar  to 
perform  multiple  functions  simultaneously  as  shown  in  Figure  5.  (O’Donnell  2010).  All 
phased  array  antennas  with  a  sufficient  number  of  elements  can  perform  multiple 
functions  if  the  control  software  allows  it;  one  must  be  cautious  in  interpreting  the  names 
and  nomenclature  of  specific  radar  systems.  For  instance,  the  SPY-3  radar  destined  for 
DDG-1000  is  commonly  known  as  the  Multi-Function  Radar  (MFR).  Likewise  Thales 
advertises  its  APAR  as  the  first  “true”  multi-function  radar  despite  Aegis’  operational 
history  since  1983  (Thales  2013,  Jane’s  2013). 
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Figure  5.  SPY-1  Functions  (from  Lockheed  Martin  2013) 


Because  of  limits  on  the  amount  of  phase  shift  that  can  be  applied  to  the  emitted 
RF  energy  in  a  phased  array,  such  systems  typically  feature  three  or  four  arrays  spaced  to 
ensure  360  degree  coverage  (White  and  Billups  2008).  Other  variations  include  a  single 
array  that  is  mechanically  moved,  creating  a  hybrid  mechanical/phased  antenna  (Skolnick 
2008). 

Phased  array  radars  are  commonly  referred  to  as  either  “active”  or  “passive.”  The 
distinction  lies  primarily  in  how  power  is  generated  in  the  radar.  “Passive”  denotes  that 
the  individual  modules  in  the  antenna  array  receive  their  power  from  a  common  source  as 
is  the  case  in  a  traditional  antenna  setup  (see  Figure  6.  ).  This  requires  extensive 
“plumbing”  to  support  the  creation  of  the  signal,  transmission  to  the  elements,  and 
environmental  controls  for  the  entire  arrangement.  The  space  required  for  the  hardware 
and  its  associated  weight  is  one  of  the  main  considerations  for  shipboard  implementation 
of  this  type  of  radar  (Harney  2005).  In  particular,  the  necessity  for  extensive  waveguide 
hardware  results  in  loss  of  signal  strength  and  potential  for  mechanical  failure  (Al-Rashid 
2009).  This  is  not  to  say  that  traditional  radars  did  not  require  extensive  apparatus  to 
operate;  it  is  merely  to  point  out  that  no  improvement  is  without  its  limitations.  As  an 
example,  the  sea-based  X-band  radar  (SBX)  developed  for  the  Missile  Defense  Agency 
(MDA)  utilized  a  phased  array  antenna.  The  radar  and  its  ancillary  equipment  are 
installed  on  a  modified  offshore  oil  drilling  platform  that  is  over  280  feet  tall  (Goldberg 
2006).  The  entire  system  weighs  over  4  million  pounds  (Skolnick  2008).  The  ongoing 
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debate  about  the  suitability  of  the  DDG-1000  or  the  DDG-51  Flight  III  as  a  suitable  host 
for  the  AMDR  depends  greatly  upon  the  eapacity  of  the  hull  to  aceommodate  the  radar 
and  its  aneillary  equipment  (O’Rourke  2012). 


Figure  6.  Typieal  Passive  Array  Arrangement  (from  O’Donnell  2010,  50) 

SPY-1  is  an  S-band  passive  phased  array  radar  (NETC  2000).  The  SPY-1  has 
4,350  elements  per  antenna  array.  The  elements  are  subdivided  in  32  “modules”  or 
“subarrays”  for  transmission  and  68  for  receipt.  This  facilitates  the  division  of  power  in 
the  array  (Jenn  2013).  Aegis  ships  have  four  arrays  positioned  to  provide  360  degree 
coverage.  The  Aegis  system  is  far  more  than  just  the  radar  information  processor-it  is  the 
heart  of  a  multi-mission  warfare  command  system  (see  Figure  7.  ).  In  addition  to  the 
SPY- 1  radar,  the  ships  utilize  the  SPG-62  fire  control  radars  for  terminal  phase 
illumination  of  targets.  The  Aegis  system  processes  the  incoming  radar  information  and 
allocates  radar  resources  to  continue  conducting  search,  track,  and  missile  uplink 
functions.  It  also  transmits  the  target  information  to  the  missiles  it  launches  and  “cues” 
the  SPG-62  radars  to  provide  the  required  terminal  phase  illumination  (Jane’s  2013).  As 
seen  in  the  diagram,  the  Aegis  system  utilizes  other  sensors  beside  the  SPY-1;  these  can 
include  other  air  and  surface  search  radars.  Use  of  these  sensors  provides  two  main 
benefits.  First,  the  additional  sensors  may  be  optimized  for  performance  in  a  certain  area 
(for  example,  the  SPS-49  is  an  extremely  long-range  air  search  radar)  that  can  augment 
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SPY-1 ’s  capabilities.  Second,  the  additional  sensors  provide  redundancy  and  provide  the 
combat  system  decision  system  with  additional  resources  to  identify,  evaluate,  and 
process  contacts. 


Figure  7.  Block  Diagram  of  Aegis  System  on  DDG-5 1  (from  Jane’s  2013) 


Active  phased  arrays,  on  the  other  hand,  feature  signal  generation  in  each 
individual  element  or  small  subset  of  elements  (Skolnik  2008).  A  typical  arrangement  is 
shown  in  Figure  8.  This  provides  several  significant  benefits.  It  eliminates  the  need  for 
extensive  waveguides  and  reduces  the  signal  loss  between  the  signal  generator  and  the 
transmitter  (Al-Rashid  2009).  It  allows  each  element  to  function  as  a  receiver,  greatly 
increasing  the  number  of  data  points  available  for  the  radar’s  associated  processors.  It 
also  allows  the  system  to  degrade  “gracefully,”  as  the  loss  of  an  individual 
transmit/receive  element  has  less  impact  on  system  performance  than  the  loss  of  an  entire 
“subarray”  or  the  loss  of  the  signal  generator  (Al-Rashid  2009).  The  active  array  retains 
all  of  the  advantages  of  the  phased  array  over  the  mechanical  antenna. 
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Figure  8.  Typical  Active  Array  Arrangement  (from  O’Donnell  2010,  49) 


The  Active  Phased  Array  Radar  (APAR)  is  an  X-band  active  phased  array  radar 
currently  in  use  by  the  Dutch  and  German  navies  (Thales  2013).  It  provides  many  of  the 
same  functions  as  Aegis,  although  it  does  not  utilize  dedicated  terminal  phase 
illumination  radars.  Instead,  APAR  itself  provides  terminal  illumination  by  commanding 
certain  T/R  elements  to  illuminate  the  target  at  the  final  stage  of  the  engagement.  The 
APAR  utilizes  Interrupted  Continuous  Wave  Illumination  (ICWI),  a  variation  of  a 
continuous  wave  beam  described  earlier,  to  perform  this  task  (Thales  2013). 

The  APAR,  like  the  SPY-1,  is  supported  by  other  onboard  sensors.  The  APAR 
radar  is  combined  with  Thales’  Signaal  Multibeam  Acquisition  Radar  for  Tracking-L 
band  (SMART-L)  radar  which  is  an  L-band,  phased  array  air  search  radar  (see  Figure  9. 
).  The  SMART-L  is  an  example  of  the  hybrid  phased  array  radars  described  earlier.  It  is 
trained  horizontally  by  moving  the  entire  array;  beamforming  and  steering  are 
accomplished  electronically  (Thales  2013). 
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Figure  9.  APAR  (left)  and  SMART -L  Radars  (from  Jane’s  2013) 

The  introduction  of  the  SPY- 1/Aegis  tandem  introduced  the  first  multi-purpose 
radar  into  the  U.S.  fleet.  The  radar  performs  air  search  and  track  and  missile  guidance 
functions  as  well  as  being  used  for  surface  search  and  track  and  gunfire  support  (NETC 
2000).  The  SPY-1  has  been  adapted  to  perform  ballistic  missile  defense  (BMD)  and  is 
currently  the  mainstay  of  short  and  intermediate  range  ballistic  missile  defense  for  the 
U.S.  and  her  allies  (Jane’s  2013).  The  APAR/SMART-L  combination  is  another  example 
of  the  multi-use  capabilities  of  the  active  antenna  array  concept  and  it  has  also  been 
tested  in  a  BMD  role  (Thales  2013). 

The  benefits  of  phased  array  antennas,  combined  with  ever-increasing  computing 
power,  allow  modem  radar  and  combat  systems  to  perform  extraordinarily  difficult 
military  tasks.  These  range  from  detection  and  engagement  of  sea-skimming  anti-ship 
cmise  missiles  to  discrimination  of  a  ballistic  missile  warhead  from  any  surrounding 
clutter  at  ranges  in  the  hundreds  of  miles  (Jane’s  2013;  Goldberg  2006).  As  such,  active 
phased  array  antennas  fit  perfectly  into  the  RMA’s  conception  of  revolutionizing  warfare 
via  technology  and  thus  it  is  no  surprise  that  such  radars  had  a  prominent  place  on  DDG- 
1000.  The  next  section  will  examine  the  development  of  these  radars  for  DDG-1000. 

2,  History  of  the  Dual  Band  Radar  on  DDG-1000 

In  conjunction  with  the  start  of  the  DD-21  program  in  1998  (described  in  Section 
B),  Raytheon  Integrated  Defense  Systems  (RIDS)  received  a  5-year,  $140  million 
development  contract  in  1999  to  begin  working  on  the  Multifunction  Radar  (MFR)  that 


29 


was  intended  for  both  DD-21  and  the  future  aircraft  carrier  program,  then-designated 
CVN-21  (DID,  2013).  Initial  concepts  included  an  X-band  multi-function  radar  paired 
with  an  L-band  volume  search  radar  (VSR),  a  configuration  very  similar  to  that  of  the 
APAR/SMART-L  system.  The  two  arrays  would  operate  in  their  respective  frequencies 
simultaneously,  with  all  radar  timing  functions,  commands,  and  so  forth  being  performed 
by  a  common  control  unit.  The  radar  controller  would  essentially  perform  many  of  the 
decision  functions  that  are  currently  performed  by  the  Aegis  combat  system.  The  concept 
of  operations  is  shown  in  Figure  10.  This  would  result  in  even  faster  processing  times 
than  those  seen  by  Aegis.  The  system  would  also  dispense  with  the  need  for  separate  fire 
control  illuminators.  It  would  also  have  the  potential  for  use  as  an  electronic  warfare 
system,  supplementing  the  current  SLQ-32,  and  would  itself  be  less  susceptible  to 
electronic  attack  (DID  2013). 
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Figure  10.  DBR  Concept  of  Operations  (from  DID  2013) 
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In  2000,  Lockheed  Martin,  the  prime  contractor  for  SPY-1  and  Aegis,  began  an 
internal  development  project  known  as  the  S-band  Advanced  Radar  (SBAR).  The  project 
was  primarily  intended  to  demonstrate  improvements  in  BMD  performance,  a  rapidly 
growing  priority  for  the  United  States  (Friedman  2006).  By  2003,  Lockheed  had  begun 
demonstrations  of  SBAR  at  its  Moorestown  facility  (Lockheed  Martin  2003).  The  Navy 
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subsequently  announeed  that  the  VSR  portion  of  DBR  would  be  S-band  instead  of  L- 
band,  and  that  Loekheed  was  to  be  the  subeontraetor  for  the  VSR  array.  Raytheon  would 
remain  the  prime  eontraetor  for  the  entire  system,  and  was  responsible  for  the  eommon 
“baek-end”  of  the  radar  suite  (DID  2013).  The  most  important  element  of  integration 
would  be  the  Radar  Suite  Controller  (RSC)  and  its  assoeiated  software.  The  RSC 
performs  the  essential  task  of  eoordinating  the  operations  of  the  radar  and  alloeating  the 
radar’s  timeline  to  meet  needs  (United  States  Navy  [USN]  2012e). 

The  radar  change  (and  its  impact  on  flow-down  requirements  such  as  footprint 
required  in  the  ship’s  deckhouse,  amount  and  type  of  ancillary  equipment,  software 
modifications,  and  so  on)  were  duly  noted  as  a  risk  in  a  2004  GAO  report  on  DDG-1000 
(GAO  2004).  The  change  also  resulted  in  schedule  delays.  The  GAO  report  is  also 
interesting  in  that  it  expressed  skepticism  of  the  Navy’s  confidence  that  all  technologies 
would  be  mature  before  installation  on  the  ship.  The  report  also  noted  that  the  Navy  had 
no  fail-back  plans  for  eight  of  the  ten  critical  technologies  and  that  schedule  slips  and 
additional  funding  would  be  the  likely  result  of  the  over-ambitious  schedule  (GAO  2004). 

The  DDG-1000  program  plan  depended  heavily  on  the  development  and  testing 
of  Engineering  Development  Models  (EDMs)  to  prove  out  the  many  new  technologies  on 
DDG-1000,  and  the  DBR  was  no  exception.  In  2005,  the  MER  EDM  completed 
Milestone  B  testing  at  the  Wallops  Island  test  facility  (DID  2013).  Milestone  B  marks  the 
approval  for  a  system  to  move  from  the  “Technology  Development”  phase  of  the 
acquisition  system  into  the  “Engineering  and  Manufacturing  Development”  phase  (DAU 
2011).  The  Milestone  B  decision  is  significant: 

Before  making  a  decision,  the  MDA  (Milestone  Decision  Authority)  will 
confirm  that  technology  is  mature  enough  for  systems-level  development 
to  begin,  the  appropriate  document  from  the  Joint  Capabilities  Integration 
and  Development  System  (see  Chapter  6)  has  been  approved,  and  funds 
are  in  the  budget  and  the  out-year  program  for  all  current  and  future 
efforts  necessary  to  carry  out  the  acquisition  strategy.  At  Milestone  B,  the 
MDA  approves  the  acquisition  strategy,  the  acquisition  program  baseline, 
the  type  of  contract  for  the  next  phase,  and  authorizes  entry  into  the 
engineering  and  manufacturing  development  phase.  The  MDA  also 
certifies  to  the  congressional  defense  committees  that  the  program  is 
affordable,  funding  is  available,  market  research  was  conducted,  an 
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analysis  of  alternatives  was  completed,  the  JROC  is  in  agreement, 
technology  has  been  demonstrated  in  a  relevant  environment,  a 
preliminary  design  review  has  been  conducted,  and  the  program  has  a  high 
likelihood  of  accomplishing  its  intended  mission  and  complies  with  all 
statutory  and  regulatory  requirements.  (DAU  2011) 

In  2006,  the  MFR  completed  at-sea  testing  onboard  the  Navy’s  Self  Defense  Test 
Ship  (SDTS).  In  October  of  that  year  RIDS  announced  that  it  was  on  schedule  with 
integration  of  Lockheed’s  S-band  array  with  the  receiver,  exciter,  and  signal  processing 
equipment  of  their  own  VSR  (DID  2013). 

In  2007,  RIDS  received  two  additional  contracts  to  continue  detailed  design  and 
integration  of  all  of  DDG-lOOO’s  Mission  System  Equipment  (MSE)  which  included  the 
DBR.  In  October  of  2007,  RIDS  completed  installation  of  the  Eockheed-centered  VSR 
with  the  MFR  located  at  the  Surface  Warfare  Engineering  Eacility  (SWEE)  in  Port 
Hueneme  and  began  an  extensive  six-month  period  of  integration  testing  (DID  2013). 

The  summer  of  2008  saw  the  final  reduction  of  the  DDG-1000  program  by  the 
Navy  and  the  announcement  of  the  re-start  of  the  DDG-51  production  line  (as  described 
in  Chapter  II).  Work  on  the  DBR  continued,  although  schedule  slips  were  beginning.  In 
December  2008,  a  Production  Readiness  Review  (PRR)  of  the  MSE  for  Zumwalt  was 
completed  successfully  (DID  2013).  A  PRR  “examines  a  program  to  determine  if  the 
design  is  ready  for  production  and  if  the  prime  contractor  and  major  subcontractors  have 
accomplished  adequate  production  planning”  (DAU  2011,  91).  While  not  strictly  a 
review  of  technological  progress,  a  “design  ready  for  production”  would  be  presumed  to 
be  a  design  without  significant  technical  problems-indeed,  one  would  expect  that  it 
would  be  tested  and  proven  to  meet  requirements. 

In  March  of  2009,  the  GAO  issued  its  annual  assessment  of  major  weapons 
programs.  The  report  specifically  described  the  S-band  VSR  as  “an  immature 
technology”  and  added; 

Eand-based  tests  of  the  volume  search  radar  prototype  will  not  be 
completed  until  June  2009  —  over  2  years  later  than  planned.  Upcoming 
land-based  tests  will  be  conducted  at  a  lower  voltage  than  needed  to  meet 
requirements — and  without  the  radome.  The  Navy  will  not  demonstrate  a 
fully  capable  radar  at  its  required  power  output  until  testing  of  the  first 
production  unit  in  201 1.  Partly  due  to  delays,  the  volume  search  radar  will 
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not  be  installed  during  deckhouse  construction  as  initially  planned. 

Instead,  installation  will  occur  in  April  2013 — after  the  Navy  has  taken 

custody  of  the  ship.  (GAO  2009) 

The  report  seemed  to  fly  in  the  face  of  the  previous  year’s  PRR  (which  is  chaired 
by  the  Navy).  Delays  with  VSR  also  had  potential  impacts  on  the  future  carrier  program 
(known  by  this  time  as  the  CVN-78  program).  The  2010  GAO  report  noted  that  the  VSR 
had  “. .  .progressed  in  maturity”  but  that  the  radar  would  still  not  be  fully  tested  until  after 
it  was  installed  in  DDG-1000  (GAO  2010,  55).  In  May  of  2010  Raytheon  announced  that 
it  had  simultaneously  tracked  targets  with  both  the  S-  and  X-band  portions  of  the  radar 
during  continued  EDM  testing  at  Wallops  Island  (DID  2013). 

The  July  2008  reduction  in  ship  numbers  (and  subsequent  budget  requests  with 
reduced  funding)  resulted  in  a  Nunn-McCurdy  breach  for  the  program.  As  a  result  of  that 
breach,  the  Navy  looked  for  ways  to  immediately  reduce  the  procurement  cost  of  the 
hulls.  In  June  of  2010,  the  Navy  made  the  decision  to  remove  the  VSR  from  DDG-IOOO 
(O’Rourke  2011).  The  VSR  was  not  cancelled;  the  entire  DBR  will  be  installed  on  CVN- 
78.  The  removal  of  the  VSR  is  estimated  to  save  roughly  $100  million  for  each  of  the 
three  DDG-1000  hulls.  Funding  for  integration  and  testing  activities  was  also  lowered  for 
DDG-1000,  although  maintained  for  CVN-78  (the  later  “need  date”  for  CVN-78  allowed 
those  activities  to  be  spread  across  further  years  of  budget  requests)  (DID  2013).  In  the 
end,  the  move  was  justified  by  the  DDG-IOOO  program  manager  in  this  way:  “. .  .we  don’t 
need  the  S-band  radar  to  meet  our  requirements... you  can  meet  requirements  with  [the] 
X-band  radar  with  software  modifications”  (O’Rourke  2012,  56). 

Although  the  VSR  was  removed  from  DDG-1000  design,  the  space  and  weight 
reservations  designated  for  installation  of  the  equipment  will  remain.  This  could  allow  for 
future  expansion  of  the  MFR,  if  the  MFR  was  further  developed  into  a  BMD  version,  or 
future  installation  of  the  new  AMDR  (DID  2013). 

In  addition,  the  MFR  will  have  to  be  modified  to  perform  many  of  the  long-range 
search  functions  that  the  VSR  was  to  have  performed.  Such  an  alteration  of  mission  and 
requirements  after  nearly  ten  years  of  development  was  not  without  impact.  These  will  be 
described  in  Chapter  IV.  The  modifications  were  also  not  without  cost,  although  the 
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Navy  and  the  Under  Seeretary  of  Defense  for  Aequisition,  Teehnology  and  Logistics 
(USDAT&L)  believed  “...the  estimated  cost  of  the  MFR  software  modification  to 
provide  the  volume  search  capability  will  be  significantly  less  than  the  estimated 
procurement  costs  for  the  VSR...”  (O’Rourke  2012,  56). 

The  MFR  will  be  installed  on  all  three  DDG-1000  ships;  contracts  for 
procurement  of  the  radars  were  issued  in  2007  and  2009  (DID  2013).  A  full  DBR 
(including  MFR  and  VSR)  has  been  funded  for  installation  in  CVN-78.  It  remains 
uncertain  if  DBR  will  be  installed  on  future  carriers.  RIDS  is  still  performing  software 
modifications  to  implement  volume  search  functionality  on  the  MFR  (DID  2013). 

E.  MISSILE  IMPLEMENTATION  ON  DDG-1000 

DDG-IOOO  has  a  requirement  to  employ  missiles  for  ship  self-defense  (O’Rourke 
2004).  The  missiles  originally  chosen  for  implementation  on  DDG-1000  were  the 
Standard  Missile  (SM)  2  Block  III-B  and  the  Evolved  Sea  Sparrow  Missile  (ESSM).  This 
section  will  briefly  describe  the  characteristics  and  operation  of  the  two  missiles  and  the 
modifications  required  to  make  them  compatible  with  the  MFR.  The  program  to 
accomplish  this  integration  of  ESSM  and  SM  into  DDG-1000  is  known  as  the  Joint 
Universal  Weapons  Link  (JUWL)  program  or  the  ICWI-JUWL  program.  It  is  important 
to  note  that  for  both  missiles,  the  JUWL  effort  was  supposed  to  result  in  a  technical  data 
package  describing  the  new  component,  several  Inert  Operational  Missiles  (lOM),  and  a 
Missile  Communication  Test  Set  (MCTS).  The  program  did  not  include  funding  for 
integration  efforts  with  the  combat  system,  funding  to  transition  the  design  to  production, 
or  any  flight  testing  of  the  hardware  (Raytheon  2012).  Those  efforts  were  expected  to  be 
scheduled  and  performed  under  the  cognizance  of  the  related  missile  programs,  and 
funded  through  their  budget  requests  or  existing  funding. 

1,  JUWL  Program  Organization 

JUWL  was  not  implemented  as  a  stand-alone  development  program.  It  was 

organized  as  a  project  under  the  direction  of  the  Program  Executive  Office  (PEO)  for 

Integrated  Warfare  Systems  (IWS)  Surface  Ship  Weapons  (Office  Code  3.0).  The  project 

manager  for  the  effort  was  assigned  from  office  code  3A  (Standard  Missile)  and  the 
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funding  for  the  project  was  added  as  a  technical  instruction  (TI)  to  the  existing 
engineering  and  technical  services  contract  for  Standard  Missile  (Raytheon  2013).  The 
prime  contractor  is  Raytheon  Missile  Systems  (RMS)  in  Tucson,  Arizona.  By  necessity, 
the  program  needed  to  interact  with  the  PEO  for  DDG-1000  and  the  PEO  for  DDG-1000 
combat  systems  as  well  as  the  prime  contractor  for  development  of  the  MER  and  the 
DDG-1000  combat  system,  Raytheon  Integrated  Defense  Systems  (RIDS)  in  Tewksbury, 
Massachusetts.  Eigure  II.  shows  the  program  organization. 


Eigure  1 1 .  JUWE  Project  Organization 


IWS  9  served  as  the  Systems  Integration  Program  Manager  (SIPM)  for  all  DDG-1000 
combat  system  elements.  PMS  500  is  the  overall  program  manager. 

The  JUWE  Statement  of  Work  (SOW)  directs  the  contractor  to  develop  link  and 
guidance  functionality  for  ESSM  and  SM  to  operate  from  DDG-1000.  It  also  specifies 
that  all  other  missile  requirements  are  unchanged.  In  other  words,  ESSM  and  SM 
requirements  are  not  altered  by  the  missile’s  implementation  with  DDG-1000  unless  it  is 

clearly  called  out  in  an  interface  document.  Indeed,  the  interface  documents  in  use  on 
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DDG-1000  are  legacy  documents  from  the  Aegis  program.  For  instance,  the  launcher 
interface  document  is  the  Mk41  VLS  interface  document-despite  the  fact  that  DDG-1000 
uses  the  new  Mk57  launcher.  While  ostensibly  identical  to  the  Mk41,  such 
“identicalness”  has  not  been  tested  in  a  practical  environment  to  date. 

2.  ESSM 

ESSM  is  an  evolution  of  the  NATO  Sea  Sparrow  missile.  Sea  Sparrow  is  a 
medium  range,  semi-active  homing,  ship  self-defense  missile  developed  in  the  late  1960s 
and  early  1970s  (USN  2012a).  Sea  Sparrow  uses  the  TAS  (Doppler  L-band)  radar  for 
initial  detection  of  targets  and  the  X-band  Continuous  Wave  (CW)  Mk95  director  for 
target  illumination.  The  missiles  are  fired  from  the  Mk29  above-deck  eight-cell  trainable 
launcher  (Friedman  2006).  Figure  12.  depicts  the  elements  of  the  Sea  Sparrow  system. 
From  left  to  right;  they  are  the  Mk29  launcher,  the  TAS,  and  two  of  the  Mk95 
illuminators. 


Figure  12.  Components  of  the  SeaSparrow  System 


ESSM  has  significant  improvements  over  SeaSparrow,  including  improved 

missile  kinematics  and  a  vertical  launch  capability.  The  ESSM  also  features  updated 

electronics,  allowing  it  to  receive  mid-course  guidance  and  terminal  illumination  from  the 

S-band  SPY-l/Aegis  system  or  the  X-band  APAR  system  (USN  2012a;  Raytheon  2013). 

The  Aegis  configured  missiles  are  capable  of  uplink  and  downlinks;  the  APAR  missiles 

are  uplink  only.  The  ESSM  is  currently  launched  from  four  different  launchers  (the 

trainable  Mk29  and  the  vertically-launched  Mk41,  Mk48  and  Mk56)  and  interfaces  with 

ten  different  combat  systems  (the  Mk57  NS  SMS,  Aegis,  APAR,  and  other  country- 

specific  systems).  Each  combat  system  and  radar  combination  requires  a  different  variant 
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of  the  ESSM  missile.  For  instanee,  an  ESSM  fired  from  the  original  SeaSparrow  system 
does  not  feature  the  thrust  veetor  apparatus  required  for  vertical  launch  and  does  not 
contain  midcourse  guidance  functionality  (DID  2013).  Figure  13.  shows  the  various 
stages  of  ESSM  operation. 
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Figure  13.  ESSM  Operation  (from  DID  2013) 

The  ready/storage  phase  denotes  the  period  onboard  the  ship  before  the  missile  is 
first  activated  for  firing.  The  missile  receives  initial  target  information  before  its  motor  is 
ignited  and  the  ESSM  leaves  its  launcher.  The  transition  phase  is  the  period  in  which  the 
missile  conducts  a  pitch  over  maneuver  to  change  from  a  vertical  flight  path  to  a 
horizontal  or  nearly  horizontal  flight  path  to  intercept  its  target.  During  the  midcourse 
phase,  the  ESSM  continuously  adjusts  its  flight  path  using  information  transmitted  from 
the  ship  to  intercept  the  target.  In  the  acquisition/homing  phase,  the  missile’s  onboard 
seeker  begins  its  search  for  the  target  by  detecting  RE  energy,  transmitted  by  the  Aegis’ 
dedicated  illuminator  or  the  APAR’s  ICWI  waveform,  reflected  from  the  target.  Once  the 
target  is  acquired,  the  missile’s  autopilot  adjusts  its  flight  path  to  intercept  the  target  as 
closely  as  possible.  The  terminal  phase  begins  when  the  ESSM  and  missile  are  entering 
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very  near  proximity;  at  that  time  the  illumination  from  the  signal  shifts  to  a  continuous 
signal,  allowing  the  ESSM  to  have  the  most  rapid  updates  possible  in  order  to  maneuver 
as  close  to  the  target  as  it  can.  The  missile’s  Target  Detection  Device  (TDD)  will 
detonate  the  warhead  at  the  optimal  time  to  achieve  the  maximum  chance  of  destroying 
the  target. 

The  ESSM,  like  SeaSparrow,  is  not  an  area  defense  weapon.  It  was  designed 
strictly  for  ship  self-defense  and  has  limited  ability  to  protect  other  vessels.  Although  its 
primary  targets  are  anti-ship  cruise  missiles,  it  does  have  a  surface  to  surface  mode  and 
can  also  be  employed  against  slower  air  targets  (USN  2012a). 

The  ESSM  missile  (Eigure  14.  )  is  composed  of  a  seeker,  guidance  section, 
warhead,  transition  section,  and  propulsion  section. 
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Eigure  14.  ESSM  sections  (from  DID  2013) 


The  antennas  for  data  link  operations  are  contained  in  the  transition  section.  Eigure  15. 


shows  the  main  sections  of  this  internal  arrangement: 
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Figure  15.  Data  Link  Components 


Figure  16.  shows  an  expanded  view  of  the  internal  arrangement  of  ESSM, 
including  interfaces  with  the  guidance  section  and  launcher. 


Figure  16.  ESSM  Guidance  Components 


As  described  in  the  phases  of  flight,  the  missile  receives  target  information  and  own 
ship  position  before  launch.  After  launch,  the  missile  receives  target  position  and  possible 
maneuvering  commands  from  the  ship  via  the  transceiver.  The  target  position  information 
is  relayed  to  the  MBC,  where  the  MBC  uses  the  information  to  issue  commands  to  the 
seeker  head  to  point  at  the  target.  The  TSC  processes  information  from  the  Inertial 
Measuring  Unit  (IMU)  and  uses  the  IMU  data,  along  with  uplink  information,  to  update 
the  missile’s  position.  That  calculation  is  compared  to  the  target  information  by  the 
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MBC,  which  in  turn  issues  steering  eommands  to  the  missile’s  eontrol  surfaees  via  the 
TSC  to  the  Steering  and  Control  System  (SCS).  The  SCS  also  returns  feedbaek  to  the 
TSC.  The  ESSM  will  begin  to  seareh  for  the  target  at  a  predetermined  time  or  when 
ordered  to  so  by  the  ship.  When  the  ESSM  is  close  enough  to  the  target,  the  illuminator 
ehanges  to  eontinuous  transmission  and  the  missile  executes  the  terminal  portion  of  the 
flight. 

Modifying  ESSM  for  JUWL  required  five  major  areas  of  effort: 

•  Replaeing  the  S-band  transeeiver  with  an  X-band  transeeiver 

•  Replaeing  the  antenna  assoeiated  with  the  transeeiver 

•  Modifying  the  TSC  software 

•  Modifying  the  MBC  software 

•  Modifying  the  VERR  software  (Raytheon  2012) 

Beeause  ESSM  already  had  a  variant  compatible  with  an  X-band  ICWI 
waveform,  the  ESSM  portion  of  the  JUWL  program  had  fewer  fundamental  ehanges  to 
perform  in  order  to  produee  a  missile  that  would  be  eompatible  with  DDG-1000.  There 
were  only  software  ehanges  needed  to  support  a  new  transeeiver/antenna  eombination 
and  software  to  support  the  new  uplink/downlink  data  formats  of  the  MFR.  The  program 
did  not  have  to  make  any  ehanges  to  the  guidanee  algorithms  in  the  MBC.  The  DDG- 
1000  ESSM  Coneept  of  Operations  (CONOP)  for  a  missile  flight  was  in  faet  based  on  the 
ESSM  APAR  CONOP.  The  ESSM  is  the  first  of  the  two  missiles  that  will  be  integrated, 
tested,  and  fired  from  DDG-1000  during  her  Initial  Operational  Test  and  Evaluation 
(lOT&E)  period  (DID  2013). 

3.  SM-2 

The  Standard  Missile  (SM)  is  an  outgrowth  of  the  Navy’s  earlier  Terrier  and 
Tartar  missile  programs.  It  is  a  “medium  to  long”  range  (up  to  90  nautieal  miles),  semi- 
aetive  homing,  area  air  defense  missile  (USN  2012b).  There  have  been  many  variants  of 
the  missile  produeed  to  date;  some  were  required  for  use  on  different  launehers  and 
others  ineorporated  performanee  improvements  (Friedman  2006).  The  U.S.  Navy  has 
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retired  earlier  versions  of  the  SM-2,  although  other  nations  still  use  them  (as  well  as  the 
earlier  SM-1  missile)  (Jane’s  2013). 

The  U.S.  Navy  currently  employs  the  SM-2  Block  III,  SM-2  Block  IIIA,  and  the 
SM-2  Block  IIIB  (USN  2012b).  Block  III  featured  flight  trajectory  improvements  over 
earlier  versions  and  the  Block  IIIA  featured  an  improved  warhead.  Block  IIIB 
incorporated  maneuverability  improvements  via  a  software  upgrade  and  also  incorporated 
an  infrared  sensor  for  terminal  homing.  The  SM-3  missile  is  a  much  larger  variant  used 
for  ballistic  missile  defense  missions.  SM-6  is  an  extended  range  variant  which  also 
features  an  active  seeker,  enabling  improved  performance  against  certain  target  types  and 
full  utilization  of  the  Navy’s  improving  Cooperative  Engagement  Capability  (CEC).  It 
may  also  eventually  be  featured  in  a  terminal  phase  BMD  role  (DID  2013). 

An  Aegis  SM  engagement  follows  a  pattern  similar  to  that  of  an  Aegis  ESSM  (see 
Eigure  17.  ).  The  ship’s  sensors  detect  and  track  a  target  and  the  combat  system  relays 
target  position  data  to  the  missile.  The  missile  is  launched  vertically  and  maneuvers  to 
bring  itself  to  the  desired  flight  path.  The  missile  receives  S-band  data  uplinks  and 
continues  to  maneuver  to  close  on  the  target.  It  also  can  downlink  information  when 
queried.  Terminal  phase  illumination  is  provided  by  the  SPG-62  illuminators  on  the  ship 
(NETC  2000). 


Command  Qf 
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Eigure  17.  Typical  Standard  Missile  Engagement  (from  Raytheon  2013) 
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SM-2  Block  IIIB  required  significant  work  to  make  the  missile  compatible  with 
the  DDG-lOOO’s  MFR.  Significant  efforts  included: 

•  The  new  frequency  and  waveform  required  modification  to  the  missile’s 
existing  receiver  (referred  to  as  Plate  1) 

•  Modification  of  the  missile’s  transmitter  (Plate  3) 

•  Modification  of  the  encoder/decoder  (Plate  4) 

•  Complete  redesign  of  the  existing  digital  signal  processor  (Plate  2) 

•  A  new  software  build  to  support  the  ICWI  waveform,  transmit  and  receive 
link  messages  to  the  MFR,  and  include  new  guidanee  algorithms  for  the 
missile  (Raytheon  2013) 

A  modernization  effort  for  Plate  2  had  already  begun  to  support  the  Standard 
Missile  program  as  a  whole,  addressing  obsolescenee  issues  and  inserting  components  to 
aeeommodate  future  growth.  It  was  known  as  the  Digital  Signal  Proeessor- 
Modernization  or  DSPM.  JUWL  was  direeted  to  integrate  with  that  effort  to  ensure  that 
the  DSPM  would  meet  JUWL  requirements  (Raytheon  2013). 

The  effort  required  to  make  SM  compatible  with  DDG-1000  was  not  trivial.  It 
required  significant  hardware  and  software  efforts.  The  SM  portion  of  JUWL  is 
scheduled  for  its  eritical  design  review  (CDR)  in  late  summer  of  2014  (Raytheon  2013). 

4,  Missile  Deliverables  and  Changes 

The  JUWL  effort  had  several  signifieant  events  affect  the  program  since  it  was 
initiated.  First,  the  original  intent  for  the  SM  JUWL  was  to  add  X-band  functionality  to 
the  missile  but  retain  S-band  compatibility.  This  would  result  in  a  truly  “universal” 
component,  reducing  costs  and  limiting  the  amount  of  configuration  changes  in  the  SM 
program.  This  requirement  was  dropped  in  2010  (Raytheon  2013). 

In  2010,  the  Navy  restructured  the  entire  DDG-IOOO  effort  as  a  result  of  the 
Nunn-MeCurdy  breaeh  and  subsequent  budget  request  changes.  As  noted,  funding  for 
integration  of  the  VSR  and  MFR  was  caneelled;  that  funding  had  also  been  used  to 
support  the  JUWL  effort.  In  January  of  201 1 ,  no  additional  funding  had  become  available 
to  support  the  JUWL  TI  and  the  prime  contractor  stopped  the  effort  and  re-assigned  or 
released  the  engineering  staff  working  on  the  projeet  (Raytheon  2011).  Additional 
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funding  was  finally  allocated  in  June  of  2011  and  RMS  began  re-assembling  its  team. 
This  delay  resulted  in  some  significant  schedule  slip  for  both  ESSM  and  SM.  While  this 
was  certainly  not  the  Navy’s  intent  when  it  restruetured  the  program  in  response  to  Nunn- 
MeCurdy,  it  had  significant  impact  on  the  prime  eontraetor’s  development  effort. 

In  the  summer  of  2012,  the  Navy  made  the  deeision  to  ehange  the  DDG-1000  SM 
missile  from  the  Bloek  IIIB  type  to  the  older  Bloek  IIIA  type  (Raytheon  2013).  This  had 
signifieant  impact  because  the  Bloek  IIIA  had  different  hardware  and  software  from  the 
IIIB.  In  partieular,  the  IIIA  does  not  eontain  the  IR  hardware  for  terminal  phase,  does  not 
eontain  the  software-driven  Maneuverability  Upgrade  (MU),  and  is  equipped  with  a 
different  TDD.  All  of  these  ehanges  affeet  JUWL.  The  absenee  of  the  IR  hardware 
altered  the  physieal  layout  of  the  plates  that  JUWL  was  designing  and  also  affeeted  the 
guidanee  software.  The  different  TDD  also  affeeted  guidanee  as  the  missile  may  need  to 
fly  different  flight  paths  against  different  targets.  The  absenee  of  MU  eould  also  have 
affected  guidanee;  however,  the  program  later  deeided  to  include  MU  funetionality  in  the 
JUWL  software  build  (Raytheon  2013). 

Linally,  the  MLR  itself  has  ehanged  in  order  to  aeeommodate  the  addition  of  some 
of  the  funetionality  of  the  deleted  VSR.  The  heart  of  a  multi-function  radar  is  the 
management  of  the  radar’s  resourees.  As  deseribed  earlier,  a  multi-function  radar 
performs  all  of  the  functions  previously  performed  by  multiple  conventional  radars.  Thus, 
a  multi-fimotion  radar  must  direet  its  RL  energy,  reeeive  signals,  proeess  those  signals, 
and  then  potentially  redireet  its  RL  energy  based  on  its  analysis.  The  radar  may  need  to 
direet  some  RL  energy  toward  mideourse  guidanee  of  a  missile,  and  may  also  need  to 
illuminate  a  target  for  the  terminal  phase  of  an  engagement,  while  simultaneously 
traeking  multiple  other  targets  and  searehing  for  new  targets. 

Consider  the  following  example.  A  multi-funetion  radar  is  operating  in  a  general 
seareh  mode  (whieh  is  pre-established,  based  on  the  operating  environment  and  expeeted 
threats).  The  radar  reeeives  return  refieetions  from  a  eertain  bearing,  range  and  altitude 
whieh  I  will  eall  position  A.  The  radar  analyzes  these  returns  with  predetermined 
algorithms  and  based  on  the  strength  and  number  of  repeated  refieetions  determines  that 

the  refieetions  are,  in  fact,  a  target.  It  then  implements  “tracking”  algorithms  which 

43 


radiate  RF  energy  to  ensure  that  the  radar  eontinues  to  reeeive  refleetions  from  the  target. 
The  algorithms  use  the  analysis  of  the  refleetions  to  predict  the  location  of  the  target 
allowing  for  error.  Faster  targets  require  more  reflections  in  order  to  keep  those  predicted 
positions  accurate.  Hence  the  radar  is  constantly  predicting  position  B  for  the  target,  then 
position  C,  and  so  on.  There  are  time  delays  associated  with  the  receipt  of  reflections, 
processing,  predictive  calculations,  commands  to  the  antenna  to  radiate  toward  a  certain 
new  position,  and  the  reiteration  of  the  process.  The  delays  can  be  significant,  even  if 
those  times  are  measured  in  fractions  of  a  second,  when  the  targets  are  moving  at  high 
speed  and/or  are  constantly  changing  course  or  speed.  When  a  radar  element  is  directed 
to  perform  a  certain  function,  it  cannot  perform  another.  Thus,  if  a  group  of  elements  are 
radiating  to  illuminate  a  target  for  the  terminal  phase  of  an  engagement,  they  cannot 
radiate  to  search  in  another  sector. 

This  entire  process  is  radar  resource  management.  It  is  the  key  improvement  of 
the  multifunction  radar  over  a  system  utilizing  conventional  radars.  A  conventional  radar 
cannot  perform  these  re-directed  tasks.  The  combat  system  is  limited  to  tracking  targets 
as  fast  as  the  radars  can  perform  and  can  “command”  only  a  very  limited  set  of  sensors. 

A  single  target  is  a  trivial  problem  for  a  multi-function  radar,  given  the  computing 
power  available  to  perform  the  calculations  and  issue  the  subsequent  commands. 
However,  the  system  can  be  overwhelmed  or  “saturated”  by  high  numbers  of  targets  and 
conflicting  demands  for  resources. 

The  following  brief  example  highlights  the  complexity  of  the  software  needed  to 
coordinate  all  of  the  possible  combinations  of  functions  for  a  multi-function  radar 
operating  in  a  target  dense  combat  scenario.  Radar  resource  management,  also  referred  to 
as  radar  timeline  or  radar  timeline  budget,  is  the  key  consideration  for  effective 
employment.  Therefore,  when  the  MFR  program  was  directed  to  implement  new 
functionality  after  almost  ten  years  of  development,  it  was  a  major  change.  Some  of  the 
changes  have  only  recently  been  conveyed  to  the  JUWL  program.  The  most  significant 
impact  may  be  that  the  MFR  has  “maxed  out”  its  radar  timeline  in  certain  scenarios  and 
therefore  may  need  to  consider  tactical  employment  changes  to  support  any  potential 
changes  in  the  future. 
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F.  SUMMARY 

Most  of  the  new  combat  systems  developed  for  DDG-1000  have  experienced 
significant  technical  challenges  or  have  seen  significant  changes  in  scope.  The  AGS 
experienced  several  years  of  delay  in  developing  a  suitable  projectile.  Although  not 
discussed  in  this  paper,  the  DDG-1000  Undersea  Warfare  (USW)  systems  had 
developmental  delays  and  technical  challenges  (DID  2013).  The  DBR  experienced  delays 
in  developing  the  S-band  VSR,  which  was  subsequently  removed  from  the  ship.  That 
removal  drove  changes  into  the  MFR,  which  is  still  in  the  process  of  incorporating 
changes  and  assessing  their  impact  on  performance  and  radar  timeline.  The  JUWL 
program  had  to  develop  new  hardware  and  software  for  both  ESSM  and  SM  and  changes 
to  the  MFR  may  yet  have  significant  impact  on  both  missiles. 
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IV.  PROCEDURES,  STANDARDS  AND  BEST  PRACTICES 


A,  INTRODUCTION 

The  federal  government,  the  Department  of  Defense,  and  the  Navy  have 
enormous  numbers  of  legislative  mandates,  governing  regulations,  and  policy  directives 
concerning  the  development  of  systems  for  government  use.  This  thesis  will  focus  only 
on  DOD-specific  directives  and  regulations. 

This  chapter  will  briefly  describe  the  DOD’s  framework  for  acquiring  systems.  It 
will  also  list  key  concepts  of  systems  engineering  that  contribute  to  successful  system 
development.  It  will  also  examine  current  management  organizational  constructs  that 
have  been  created  in  an  attempt  to  help  management  personnel,  both  civilian  and 
military,  succeed  in  this  challenging  environment. 

B,  THE  DEFENSE  ACQUISITION  SYSTEM 

The  Defense  Acquisition  System  (DAS)  is  intended  to  produce  successful 
acquisition  programs.  A  successful  program  “...places  a  capable  and  supportable  system 
in  the  hands  of  users  (the  warfighter  or  those  who  support  the  warfighter),  when  and 
where  it  is  needed,  at  an  affordable  price”  (Defense  Acquisition  University  (DAU)  2010, 
5).  The  term  “Defense  Acquisition  System”  usually  refers  to  the  specific  rules  governing 
the  administration  of  acquisition  programs  in  the  DOD,  but  is  sometimes  more  generally 
applied  to  the  interactions  of  Congress,  the  executive  branch,  and  industry  (DAU  2010). 
For  purposes  of  this  thesis,  DAS  will  refer  to  the  specific  administration  of  military 
programs  and  the  term  “acquisition  environment”  (AE)  will  refer  to  the  broader 
interaction  of  Congress,  the  President,  industry,  and  the  respective  influences  of  public 
opinion,  media,  and  so  forth  (see  Figure  18. 

The  executive  branch  includes  the  presidential  administration,  the  uniformed 
services,  and  all  civilian  staff  in  the  DOD.  The  legislative  branch  includes  all 
Representatives  and  Senators  as  well  as  their  personal  staffs  and  the  full-time 
Congressional  staff.  Industry  encompasses  all  of  the  major  defense  industry  corporations 

and  smaller  businesses  supporting  the  defense  industry  or  the  DOD  (DAU  2010). 
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Figure  18.  The  Acquisition  Environment  (from  DAU  2010,  2) 

The  DAS  is  just  one  of  three  so-called  “decision  support  systems”  created  by 
Congress  and  the  Executive  Branch  to  determine  what  systems  should  be  acquired,  how 
they  will  be  paid  for,  and  how  they  will  be  produced  (see  Figure  19.  The  others  are  the 
Planning,  Programming,  Budgeting  and  Execution  (PPBE)  process  and  the  Joint 
Capabilities  Integration  and  Development  System  (JCIDS)  (DAU  2010,  18). 


DoD  Decision  Support  Systems 
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Figure  19.  Three  Decision  Support  Systems  (from  DAU  2013,  6) 
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The  JCIDS  process  analyzes  projected  military  capability  needs  and  shortfalls 
which  are  submitted  by  the  various  regional  and  functional  Combatant  Commanders 
(COCOMs).  If  the  JCIDS  analysis  determines  that  there  is  a  need  for  a  new  military 
system  to  meet  these  capabilities  or  shortfalls,  the  DOD  names  a  Defense  Acquisition 
Executive  (DAE)  to  oversee  the  fulfillment  of  the  requirement.  The  basic  JCIDS  process 
is  shown  in  Eigure  20. 


Eigure  20.  JCIDS  Overview  (from  DAU  2010,  36) 


The  DAE,  in  turn,  determines  the  proper  chain  of  command  to  manage  the 
development  of  the  new  system  and  establishes  the  responsible  program  office  (see 
Eigure  21.  The  DAS  allows  for  a  great  deal  of  flexibility  in  organization,  and  not  every 
program  will  align  neatly  with  the  chain  shown  in  the  figure.  Because  of  cost,  national 
strategic  importance,  or  other  reasons,  some  programs  will  not  feature  a  Program 
Executive  Office  (PEO)  between  the  program  manager  and  the  Component  Acquisition 
Executive  (CAE).  Conversely,  for  service-specific  or  less  costly  programs,  the  DAE  may 
delegate  authority  to  the  service  itself 
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Figure  21 .  Generic  Acquisition  Chain  of  Command  (from  DAU  2010,  25) 


The  DAS  is  perhaps  best  described  as  a  phased  sequence  of  technological 
development  intended  to  produce  a  successful  system.  It  is  a  management  construct  and 
is  designed  to  be  flexible  in  application.  For  example,  not  every  program  begins  at  the 
first  stage  (material  solution  analysis).  Some  programs  which  feature  a  proven  design 
applied  in  a  new  environment  could  enter  at  a  later  phase  (DAU  2011). 

Spaced  throughout  the  various  phases  are  a  series  of  demonstrations,  technical 
reviews,  and  programmatic  “milestone”  decisions.  A  high-level  view  of  the  DAS  is 
shown  in  Figure  22.  The  intention  of  the  DAS  is  to  ensure  that  the  original  requirements 
of  the  system  are  met  by  its  design.  It  is  also  intended  to  ensure  that  all  aspects  of  a 
system  throughout  the  system’s  anticipated  life  cycle  are  addressed  in  the  early  stages  of 
design  and  development. 
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The  Materiel  Development  Decision  precedes 
eniry  into  any  phase  oi  the  acquisition 
management  system 
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Figure  22.  DAS  Overview  (from  DAU  2010,  41) 


For  example,  design  of  the  system  should  take  into  account  the  anticipated 
maintenance  cycle  of  the  system,  or  conversely,  the  system  should  be  designed  to  meet 
the  maintenance  requirements  needed  by  the  warfighter.  These  decisions  can  have  an 
enormous  impact  on  system  cost  and  development  time.  Continuing  with  the  maintenance 
example,  consider  the  implications  of  maintenance  of  a  shipboard  diesel  engine  compared 
with  a  surveillance  satellite.  A  great  deal  of  diesel  engine  maintenance  and  repair  can  be 
performed  by  the  ship’s  engineers,  and  the  engine’s  consumables  and  spare  parts  can  be 
introduced  into  the  existing  ship  supply  system.  The  satellite,  on  the  other  hand,  will 
likely  never  receive  a  maintenance  visit  of  any  kind.  Hence  the  satellite  must  be  designed 
and  manufactured  to  an  enormously  higher  standard  for  reliability,  workmanship,  and 
overall  quality.  Such  demands  are  commensurately  more  expensive. 

Other  examples  of  system  design  which  should  be  addressed  in  the  early  stages  of 
design  include  (Blanchard  and  Fabrycky  1998): 

•  Required  Performance 

•  Physical  characteristics 

•  Maintenance  concept 

•  Reliability 

•  Transportability 

•  Human  Factors  (ergonomics) 
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•  Safety 

•  Producibility 

•  Testability 

•  Faeilities 

•  Support  personnel 

•  Disposability 

•  Obsoleseenee 

•  Future  improvements 

•  Packaging,  handling,  storage  and  transportation 

•  Environment 

The  list  shown  is  by  no  means  complete.  Many  factors  could  be  related;  consider 
how  physical  dimensions  of  the  system  could  be  limited  by  the  intended  transportation 
method.  This  consideration  of  the  total  life  cycle  of  a  design,  known  as  “life-cycle 
engineering,”  is  a  hallmark  of  the  systems  engineering  process  and  one  of  the  essential 
elements  for  design  success  (Blanchard  and  Fabrycky  1998). 

The  PPBE  system  is  the  method  by  which  the  DOD  produces  its  budget.  It  is  a 
complicated  process  and  will  only  be  briefly  described.  The  process  was  originally 
implemented  by  Secretary  of  Defense  Robert  McNamara  in  1962  (Army  Eorce 
Management  School  (AEMS)  2011).  The  key  feature  of  McNamara’s  new  process  was  an 
attempt  to  plan  for  and  control  change.  Instead  of  producing  and  submitting  single  year 
budgets  independently  (as  the  services  had  done  previously),  the  services  now  submitted 
five  year  projections  to  the  Office  of  the  Secretary  of  Defense  (OSD)  to  be  consolidated 
into  a  Euture  Years  Defense  Plan  (EYDP).  This  is  the  main  tool  by  which  OSD  (and  by 
extension  the  president  in  his  role  as  commander-in-chief)  determine  the  size  and  type  of 
military  forces  to  procure  and  operate  to  meet  its  strategic  needs  (AEMS  2011).  The 
EYDP  is  probably  best  considered  as  a  five-year  spending  plan,  which  the  DOD  uses  to 
submit  its  annual  budget  to  Congress.  Once  the  budget  is  enacted  into  law,  the  DOD  then 
spends  (executes)  the  budgeted  funds. 
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When  changes  to  the  five  year  plan  are  deemed  necessary,  the  services  submit 
change  requests  to  OSD  for  consideration.  To  manage  the  number  of  change  requests 
produced,  the  OSD  issues  strategic  and  budgeting  guidance  to  the  services  each  year 
which  highlights  DOD  priorities  and  adjustments  to  overall  strategy.  Thus,  the  PPBE 
system  is  a  never-ending  cycle  of  planning,  spending,  and  accommodating  changes  in 
national  strategy  and  military  priorities  that  in  turn  affect  budgets. 

Each  service  has  an  internal  process  to  produce  its  five  year  inputs  as  well  as  the 
current  years’  budget  requests.  This  is  driven  by  OSD  guidance  as  well  as  by  the 
service’s  assessment  of  its  needs  to  meet  national  strategic  guidance.  These  budget 
requests  are  consolidated  by  OSD  and  flow  into  the  president’s  budget  submission  to 
Congress  (see  Eigure  23. ). 
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Figure  23.  PPBE  Service  &  OSD  Actions  (from  DAU  2011,  20) 


Congressional  action  on  the  budget  follows  the  process  shown  in  Figure  24. 
Congress  often  disregards  the  recommendations  of  OSD  and  the  individual  services  in 
order  to  fund  programs  it  deems  important  or  cancel  programs  it  deems  too  costly.  These 
Congressional  decisions  then  affect  the  program  estimates  and  budgets  for  subsequent 
years. 
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Figure  24.  Congressional  Action  on  the  Budget  (from  DAU  2011,  21) 

This  brief  summary  does  not  capture  the  many  intricacies  of  budgeting, 
scheduling,  and  reporting  needed  by  the  DOD  to  operate  in  the  acquisition  environment. 

The  complex  interactions  of  the  PPBE,  JCIDS,  and  DAS  are  one  of  the  main 
reasons  that  the  DOD  employs  such  a  vast  bureaucracy.  Cost  analysts,  contracting 
specialists,  and  administrators  are  needed  to  fulfill  the  voluminous  reporting  and 
budgeting  documentation  needed  by  thousands  of  individual  acquisition  programs  across 
all  the  services.  A  quick  glance  at  the  latest  version  of  the  “Integrated  Defense 
Acquisition,  Technology,  &  Logistics  Life  Cycle  Management  System”  chart,  kno’wn  as 
the  “wall  chart”  or  “horse  blanket”  chart,  will  give  some  idea  of  the  multitude  of 
activities  and  procedural  steps  faced  by  even  a  relatively  small-scale  acquisition  program 
(DAU  2013,  11). 

The  DOD  recognizes  this  complexity  and  has  taken  steps  to  aid  the  services  and 
their  respective  program  offices  in  navigating  through  the  process.  The  next  section  will 
discuss  the  DOD’s  systems  engineering  infrastructure  and  describe  how  the  infrastructure 
is  designed  to  aid  in  the  design,  development,  and  production  of  effective  and  affordable 
military  systems. 
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c. 


SYSTEMS  ENGINEERING  IN  THE  DEPARTMENT  OF  DEFENSE 


The  DOD  has  recognized  the  importance  of  implementing  robust  systems 
engineering  principles  into  the  DAS  and  into  acquisition  program  management.  The  OSD 
established  an  additional  Office  of  the  Deputy  Assistant  Secretary  of  Defense  for  Systems 
Engineering  (ODASD-SE)  in  order  to  provide  guidance  and  oversight  for  implementing 
quality  systems  engineering  in  the  DOD.  The  Office’s  mission  statement  is: 

...to  develop  and  grow  the  Systems  Engineering  capability  of  the 
Department  of  Defense — through  engineering  policy,  continuous 
engagement  with  Component  Systems  Engineering  organizations,  and 
substantive  technical  engagement  throughout  the  acquisition  life  cycle 
with  major  and  selected  acquisition  programs.  We  apply  best  engineering 
practices  to: 

•  Help  program  managers  identify  and  mitigate  risks 

•  Shape  technical  planning  and  management 

•  Support  and  advocate  for  DOD  Component  initiatives 

•  Provide  technical  insight  to  OSD  stakeholders 

•  Identify  systemic  issues  for  resolution  above  the  program  level.  (ODASD- 
SE  2013) 

Numerous  studies  have  determined  that  disciplined  implementation  of  systems 
engineering  principles,  which  can  fall  under  Blanchard  and  Eabrycky’s  general  term  of 
“life  cycle  engineering,”  correlate  directly  to  improved  project  performance  in  terms  of 
cost,  schedule,  and  product  performance.  Eor  example,  a  2012  study  conducted  by  the 
Systems  Society  of  the  International  association  of  Electrical  and  Electronics  Engineers 
(IEEE)  and  the  National  Defense  Industrial  Association  (NDIA)  showed  that  only  15%  of 
projects  that  failed  to  apply  thorough  and  early  SE  achieved  established  project  success 
criteria.  The  projects  that  did  implement  early  and  effective  SE  achieved  a  57%  success 
rate.  The  difference  was  even  greater  for  those  projects  deemed  to  have  a  high 
complexity  rating  (Elm  and  Goldenson  2012,  74).  This  is  not  a  new  result.  The  related 
disciplines  of  systems  engineering  and  project  management  have  achieved  near-universal 
acceptance  in  engineering  and  industry  for  over  60  years  (Stuckenbruck  2008;  Honour 
2013).  As  we  shall  see  in  later  sections  of  this  thesis,  however,  acceptance  does  not 
automatically  translate  into  effective  application. 
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Congress  also  established  a  system  of  professional  edueation  for  personnel 
employed  in  the  DAS  with  the  passage  of  the  1990  Defense  Aequisition  Workforee 
Improvement  Aet  (DAWIA).  The  law  stemmed  from  the  1986  Paekard  Commission 
Report  that  eoneluded  military  and  eivilian  offieials  involved  in  defense  proeurement 
were  typieahy  undertrained  and/or  inexperieneed  (Fox  2011).  DAWIA  established  a 
robust  system  of  training  and  eertifioation  in  a  variety  of  eareer  fields  for  both  uniformed 
and  eivilian  personnel  in  the  DOD  (DAU  2010). 

ODASD-SE  eontinues  to  stress  the  development  of  a  professional  aequisition 
workforee.  Consider  the  following  statement  from  the  ODASD-SE: 

One  of  our  greatest  ehahenges  may  be  in  our  approaehes  to  building  great 
people  and  teams  and  improving  how  we  reeruit,  grow,  and  mature  the 
teehnieal  and  systems  engineering  professionals  who  will  suoeessfuhy 
deliver  today  and  tomorrow’s  oritieal  defense  systems.  We  are  working 
elosely  with  the  DOD  Components  to  enhanee  the  eapability  and  eapaeity 
of  the  teehnieal  management  workforee.  As  an  example,  we  are 
identifying  workforee  eompeteneies  erueial  for  exeeuting  systems 
engineering  and  produetion,  quality,  and  manufaeturing  funetions  within 
aequisition  programs.  (ODASD-SE  2013) 

The  Defense  Acquisition  Guidebook  ineludes  a  signifieant  ehapter  on  systems 
engineering  and  ah  of  the  serviees  have  their  own  systems  engineering  guidanee  for 
program  managers.  Eor  example,  the  various  naval  systems  eommands  eombined  to  issue 
the  Naval  Systems  Engineering  Guidebook  and  the  Air  Eoree  publishes  The  Early 
Systems  Engineering  Guidebook  and  the  Systems  Engineering  Primer  &  Efandbook. 
These  guides  eite  aeademie  and  professional  literature  eoneerning  SE  definitions, 
teehniques,  and  best  praetiees.  Examples  inelude  the  Systems  Engineering  Handbook 
published  by  the  International  Couneil  on  Systems  Engineering  (INCOSE)  and  the  IEEE 
Systems  Journal.  ODASD-SE  maintains  a  standards  and  speeifieations  database  of  over 
111,000  doeuments  (ODASD-SE  2013).  It  also  provides  a  teehnieal  interfaee  with  the 
International  Organization  for  Standardization  (ISO). 

The  ereation  of  systems  engineering  direetorates  in  OSD  and  ah  the  serviees,  as 
well  as  the  voluminous  amount  of  SE  guidanee  for  program  managers  and  aequisition 
professionals,  is  testament  to  the  importanee  that  the  DOD  attaehes  to  effeetive  SE  as  a 

means  to  “solve”  the  problems  that  have  plagued  military  aequisition.  Given  that 
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emphasis,  it  is  important  to  describe  some  of  the  SE  principles  that  lead  to  program 
success. 

1,  Requirements 

Establishing  requirements  that  are  clear,  valid,  achievable,  and  remain  constant  is 
one  of  the  most  commonly  cited  necessities  for  the  completion  of  a  successful 
engineering  project  (Defense  Acquisition  Guidebook  (DAG)  2013).  Requirements  are  the 
expression  of  the  “need”  that  drives  creation  of  the  system.  They  are,  by  necessity, 
established  early  in  the  life  of  the  program.  The  first  phase  of  the  DAS  -  the  material 
solution  analysis  phase-is  fundamentally  the  process  of  establishing  requirements, 
validating  and  verifying  them,  and  creating  the  concepts  and  project  plans  to  meet  those 
requirements  (see  Figure  25.  ). 
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Figure  25.  Material  Solution  Analysis  Phase  (from  DAU  2011,  83) 


Blanchard  and  Fabrycky’s  Systems  Engineering  &  Analysis,  a  widely  used 
systems  engineering  textbook,  describes  requirements  this  way: 


58 


...(T)rue  system  requirements  need  to  be  well  defined  and  specified,  and 
the  traceability  of  these  requirements  from  the  system  level  downward 
needs  to  be  visible.  In  the  past,  the  early  “front-end”  analysis  as  applied  to 
many  new  systems  has  been  minimal.  The  lack  of  defining  an  early 
“baseline”  has  resulted  in  greater  individual  design  efforts  downstream. 

Many  of  these  are  not  well  integrated  with  other  design  activities,  causing 
costly  modifications  later  on.  (Blanchard  and  Fabrycky  1998,  24) 

Similarly,  the  National  Aeronautics  and  Space  Administration  (NASA)  NASA 
Systems  Engineering  Handbook  states  “...clear  and  unambiguous  requirements  will  help 
avoid  misunderstandings  when  developing  the  overall  system  and  when  making  major  or 
minor  changes”  (NASA  2006,  32).  The  Defense  Acquisition  Guidebook  states  that 
“...poorly  written  requirements  can  lead  to  significant  problems  in  the  areas  of  schedule, 
cost,  or  performance,  and  can  thus  increase  program  risk”  (DAG  2013,  158). 

The  Defense  Acquisition  University  provides  the  mandated  training  for  program 
managers  and  systems  engineers  specified  by  the  DAWIA  act.  One  of  its  foundation 
courses  is  “Systems  Engineering  Fundamentals”  which  contains  the  following  attributes 
of  a  good  requirement; 

It  must  be  complete  and  contain  all  mission  profiles,  operational  and  maintenance 
concepts,  utilization  environments  and  constraints... 

Requirements  analysis  should  result  in  a  clear  understanding  of: 

Functions:  what  the  system  has  to  do. 

Performance:  How  well  the  function  has  to  be  performed. 

Interfaces:  Environment  in  which  the  system  will  perform.  (DAU  2001, 
36-37) 

Establishing  clear  and  comprehensive  requirements  fulfills  two  purposes  in  a 
project.  First,  it  ensures  that  the  project  will  meet  its  intended  purpose  and  therefore  that 
the  project  is  satisfying  the  “big  picture.”  Although  this  seems  self-evident,  more  than 
one  project  has  been  initiated  because  of  “...personal  interest  or  political  whim,  without 
first  having  adequately  defined  the  requirement”  (Blanchard  and  Fabrycky  1998,  46). 
Second,  requirements  drive  the  functional  analysis,  which  ultimately  produces  the  system 
conceptual  design.  The  conceptual  design,  in  turn,  feeds  the  creation  of  the  detailed 
design  and  the  eventual  configuration  to  be  fielded.  Hence  it  is  essential  that  the 
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requirements  be  complete  so  that  the  system  designers  account  for  every  system  need 
without  having  to  reallocate  or  redesign,  both  costly  and  time-consuming  activities. 

2,  Integration 

Integration  is  another  essential  element  of  systems  engineering.  Integration  of 
system  elements  is  what  produces  the  benefit  of  a  system  (Madni  2012).  In  many 
discussions  of  systems  engineering,  integration  is  approached  as  one  of  the  many 
required  processes  on  the  “upward”  portion  of  the  SE  “V”  model  (shown  in  Figure  26.  ) 
(Blanchard  and  Fabrycky  1998). 
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Figure  26.  V  Model  of  Systems  Engineering  (from  DAG  2013) 


In  this  “process”  focused  point  of  view,  system  integration  (SI)  can  be 
accomplished  using  a  variety  of  techniques.  All  of  these  techniques  stem  from  the 
traditional  “waterfaU”  model  of  SE  (precursor  to  the  “V”);  several  were  developed  in 
response  to  the  ever-increasing  complexity  (and  consequently  more  difficult  integration) 
of  modern  systems  (Madni  2012).  Methods  of  integration  include  the  layered  integration, 
“plug-and-play”  integration,  horizontal  integration,  and  build  integration  (Madni  2012). 
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While  certainly  a  valuable  benefit  of  the  SE  process,  if  one  views  SE  as  a  series  of 
processes  to  be  accomplished,  integration  is  much  more  fundamental  than  merely  a 
process  to  ensure  system  components  are  compatible. 

Professors  Gary  Eangford  and  Derek  Hitchins  have  presented  complimentary 
views  of  the  critical  importance  of  integration  to  the  success  of  any  SE  project.  Hitchins 
approaches  integration  from  his  “macro”  level  discussions  of  systems  thinking  and  the 
benefits  of  SE  design  “synthesis”  versus  the  traditional  “reductionist”  engineering 
approach  (Hitchins  2013).  Eangford,  on  the  other  hand,  presents  a  “micro”  level  view  of 
integration  and  creates  a  framework  for  conducting  integration  and  analysis  while  also 
emphasizing  the  absolute  centrality  of  integration  to  engineering  success  (Eangford 
2012). 

Hitchins’  views  on  systems  engineering  and  integration  can  be  found  in  his 
several  books  and  numerous  essays  published  at  his  website  “Systems  World” 
(www.hitchins.net).  His  “Eirst  Principle  of  Systems”  and  “Corollary  to  the  Pirst 
Principle”  are  particularly  useful:  The  properties,  capabilities,  and  behavior  of  a  system 
derive  from  its  parts,  from  interactions  between  those  parts,  and  from  interactions  with 
other  systems.  Altering  the  properties,  capabilities,  and  behavior  of  any  of  the  parts,  or 
any  of  their  interactions,  affects  other  parts,  the  whole  system,  and  interacting  systems 
(Hitchins  2013).  That  definition  captures  the  importance  of  understanding  that  a  system 
can  produce  results  greater  than  any  of  its  constituent  parts.  He  uses  the  term 
“emergence”  to  denote  this  phenomenon  and  emphasizes  that  emergence  is  the  key  to 
understanding  the  value  to  be  gained  by  pursuing  systems  engineering  principles. 

A  naval  anti-ship  cruise  missile  (ASCM)  defense  system  is  a  good  example  of 
emergence  resulting  from  integration.  Radars  and  other  sensors  cannot  defend  the  ship. 
Electronic  warfare  may  defeat  some  threats  but  not  others;  some  threats  may  or  may  not 
be  susceptible  to  decoys;  and  defensive  weapons  (guns  and  missiles)  may  or  may  not 
defeat  still  other  threats.  But  a  combination  of  all  of  those  systems  provides  the  defending 
ship  a  higher  probability  of  defeating  enemy  missiles.  Hence,  the  process  that  creates 
emergence  (integration)  has  to  be  the  centerpiece  of  any  development  effort. 
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Langford’s  recent  text  Engineering  Systems  Integration:  Theory,  Metrics,  and 
Methods  presents  an  integration  framework  that  is  abstract  enough  to  be  applied  to  any 
system  regardless  of  nature  or  complexity  (Langford  2012).  It  considers  object 
integration  in  terms  of  the  exchange  of  energy,  matter,  material  wealth,  and  information 
(EMMI)  as  influenced  by  various  boundary  conditions  -  physical,  functional,  and 
behavioral.  Langford  also  proposes  a  list  of  seven  integration  principles,  gathered  from 
numerous  case  studies,  that  “...can  help  guide  decisions”  concerning  the  conduct  of  an 
engineering  project  (Langford  2012,  10).  The  principles  are  listed  in  Appendix  A;  their 
applicability  to  DDG-1000  missile  integration  will  be  discussed  in  Chapter  V. 

Integration  is  not  easy,  and  it  is  not  a  single  well-defined  process.  Instead,  it  is 
often  practiced  in  an  ad-hoc  manner  or  in  accordance  with  the  opinions  of  various 
program  managers  or  engineers  (Madni  2012,  3).  However,  Langford  and  Hitchins  make 
compelling  arguments  that  integration  is  the  most  important  part  of  system  development 
because  it  is  the  process  that  produces  emergence.  Chapter  V  will  assess  integration  for 
DDG-1000  from  this  viewpoint. 

3,  Management  and  Organization 

The  practice  of  project  management  has  long  been  associated  with  systems 
engineering  and  is  critical  to  the  eventual  success  of  any  engineering  effort  (Blanchard 
and  Fabrycky  1998;  DAU  2001).  Just  as  a  well-organized  effort  will  fail  without  quality 
engineering,  quality  engineering  alone  will  not  guarantee  project  success.  Indeed,  one  can 
reasonably  argue  that  successful  engineering  is  a  byproduct  of  successful  management. 

What  does  engineering  management  entail?  At  a  minimum,  management  connotes 
planning,  staffing,  monitoring  and  controlling  the  design,  development,  testing,  and 
production  of  a  system  (Blanchard  and  Fabrycky  1998).  It  therefore  covers  the  initial 
problem  analysis  and  customer  requirements,  resulting  in  analysis  of  alternatives  and 
recommended  solutions.  It  includes  the  creation  of  a  detailed  work  breakdown  structure 
(WBS)  that  will  inform  budget  estimates.  It  also  includes  completion  of  functional 
flowdown  analysis,  creation  of  derived  requirements,  establishment  of  technical  reviews 
and  test  activities,  and  creation  of  a  mechanism  to  review  design  changes  and  resolve 
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technical  problems.  Lastly,  in  includes  the  preparation  of  key  program  documents  that 
capture  the  items  listed.  These  key  documents  include  an  integrated  master  schedule 
(IMS),  a  systems  engineering  management  plan  (SEMP),  the  WBS,  and  a  test  and 
evaluation  master  plan  (TEMP). 

The  elements  of  management  described  entail  the  organization  and  activities  that 
must  be  conducted  by  the  designer/producer  of  the  system  in  question.  In  the  Department 
of  Defense,  however,  the  purview  of  managing  an  acquisition  project  is  much  greater.  As 
described  in  earlier  sections  on  the  DAS  and  the  acquisition  environment,  the  project 
manager  must  contend  with  a  budgeting  process  in  which  his  or  her  project  is  likely  one 
small  piece  of  a  much  larger  puzzle.  The  manager  must  also  contend  with  possible 
requirement  changes  and  oversight  activities  that  increase  the  demand  on  project 
resources.  Eastly,  elements  of  design,  test  and  support  for  the  system  being  designed  are 
not  under  the  control  of  the  project  manager.  Thus,  the  project  becomes  dependent  on 
other  organizations  with  their  own  schedule,  budget,  and  performance  constraints. 

The  DOD  initiated  the  concept  of  Integrated  Product  and  Process  Development 
(IPPD)  in  the  early  1990s  in  order  to  foster  the  communication  and  teamwork  necessary 
to  produce  a  successful  project  in  the  acquisition  environment  (Blanchard  and  Eabrycky 
1998,  634).  A  central  element  to  IPPD  is  the  creation  and  use  of  Integrated  Product 
Teams  (IPTs)  to  manage  the  interaction  of  program  functions  (logistics,  production,  etc.) 
with  the  personnel/organizations  that  will  carry  out  the  function  (contractors,  DOD  test 
organizations,  etc.).  Eigure  27  shows  a  traditional  program  structure,  a  purely  functional 
structure,  and  a  matrix  structure  utilizing  IPTs. 
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Matrix  Structure 
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NOTE  1 :  Functional  titles  shown  are  notional. 
NOTE  2:  IPTs  often  align  with  WBS  elements. 


Figure  27.  Program  Organization  Examples  (from  DAU  2011,  56) 


The  IPPD/IPT  construct  is  a  multi-disciplinary  task  approach  and  as  such  it  is 
extremely  dependent  on  clear  lines  of  communication  to  function  efficiently  (Blanchard 
and  Fabrycky  1998,  628).  Stating  a  need  for  good  communication  in  a  large  and  complex 
organization  is  something  of  a  truism;  however  personal  experience  has  shown  that  there 
are  still  many  occasions  in  which  one  element  of  a  program  was  unaware  of  important 
developments  elsewhere  in  the  project.  The  IPTs  must  also  be  empowered  to  make 
decisions  related  to  their  functional  area  and  ensure  that  the  ramifications  of  such 
decisions  were  considered  beforehand. 
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A  matrix  organization  as  shown  will  inevitably  encounter  issues  that  will  have  to 
be  resolved  at  a  higher  level.  In  the  end,  the  responsible  program  manager  (PM)  must 
make  the  difficult  decisions.  However,  analysis  of  the  matrix  organization  and  the  DAS 
show  that  the  PM  will  often  not  have  the  final  say,  and  may  have  to  defer  to  a  higher 
level  authority  or  a  component  head  for  a  decision  in  a  certain  area.  The  implications  of 
this  organization  for  DDG-1000  will  be  examined  in  Chapter  V. 

D,  SUMMARY 

Defense  acquisition  is  a  complex  process.  The  DOD  has  made  substantial  efforts 
to  implement  systems  engineering  and  the  life  cycle  viewpoint  into  the  acquisition 
process.  Congress  has  established  professional  education  and  certification  requirements 
to  emphasize  the  importance  of  SE  in  the  DOD. 

Successful  SE  must  include  early  establishment  of  quality  requirements  for  the 
system.  Integration  activities  produce  the  emergent  behavior  that  gives  the  system  its 
value,  therefore  integration  must  also  be  emphasized  from  the  start  of  the  program.  The 
DOD  has  implemented  the  IPPD/IPT  model  into  program  management  in  order  to 
improve  communication  and  coordination  between  the  multiple  disciplines  involved  in 
developing  a  system,  including  various  design  and  engineering  areas,  logistics  planning, 
maintenance  planning,  in-service  support,  and  so  on. 

Having  discussed  the  pertinent  aspects  of  the  defense  acquisition  process  and  the 
key  systems  engineering  principles  inherent  in  all  successful  programs,  we  will  now  turn 
our  attention  to  analysis  of  the  DDG-1000  program  with  respect  to  requirements, 
integration,  and  organization. 


66 


V.  ANALYSIS 


A,  INTRODUCTION 

At  this  point  we  have  developed  our  understanding  of  the  history  and  background 
of  the  DDG-1000  program  including  its  combat  system  components.  We  have  also 
discussed  the  DOD’s  standard  planning,  acquisition  and  budgeting  processes  and  their 
efforts  to  incorporate  Systems  Engineering  where  appropriate.  Armed  with  that 
background,  we  can  analyze  the  success  or  failure  of  DDG-1000  missile  integration  with 
respect  to  the  key  systems  engineering  tenets  of  requirements,  integration  and 
organization.  The  analysis  will  be  further  informed  by  additional  illustrations,  best 
practices,  and  lessons  learned  from  other  DOD  and  commercial  industry  programs. 

B,  REQUIREMENTS 

Chapter  IV  gave  several  statements  from  a  variety  of  systems  engineering 
authorities  on  the  absolute  criticality  of  clear,  comprehensive  requirements  for  a 
development  program.  These  sources  were  academic  (Blanchard  and  Fabrycky)  and  from 
the  DOD  (the  Defense  Acquisition  Guidebook).  There  are  many  other  systems 
engineering  textbooks  and  definitions  that  similarly  echo  the  importance  of  clear 
requirements. 

Given  the  widespread  recognition  of  the  importance  of  “good”  requirements,  one 
would  believe  that  the  DOD  would  take  great  pains  to  ensure  clear  and  comprehensive 
requirements  were  established  for  all  of  its  programs.  Yet  poor  requirements  definition 
continues  to  plague  the  DOD.  For  example,  a  2003  report  from  the  NDIA  stated 
“...requirements  definition,  development,  and  management  is  not  applied  consistently 
and  effectively...”  (NDIA  2003).  The  report  continued:  “the  Government,  for  the  most 
part... do  not  follow  their  requirements  process  effectively... there  is  a  serious  lack  of 
upfront  and  continuous  requirements  development  and  management,  including 
management  of  requirements  changes”  (NDIA  2003). 

In  2006,  Secretary  of  the  Navy  Donald  Winter  stated  “...the  Navy  needs  to  do  a 

better  job  of  stabilizing  requirements.  Scrubbing  requirements  at  the  beginning  of  a 
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program  is  critical.  But  we  also  need  to  strietly  eontrol  new  requirements  in  existing 
programs...”  (Winter  2006,  4).  One  of  ODASD-SE’s  top  six  priorities  for  2013  is  to 
“...support  realistie  program  formulation  through  the  application  of  development 
planning  and  early  systems  engineering...”  and  “...identifying  early  systems  engineering 
gaps  and  defieiencies...”  (ODASD-SE  2013). 

A  2010  Air  Eoree  Institute  of  Teehnology  (AFIT)  ease  study  analysis  of  eight 
major  aequisition  programs,  both  suceessful  and  unsuceessful,  found  that  inadequate  or 
ehanging  requirements  were  a  major  reason  for  poor  performanee  in  every  unsueeessful 
program;  eonversely,  all  of  the  sueeessful  programs  were  found  to  have  elear 
requirements  that  were  adhered  to  throughout  development  (AFIT  2010). 

Missile  integration  for  DDG-1000  has  three  signifieant  potential  problem  areas  in 
terms  of  requirements;  each  concern  applies  equally  to  both  ESSM  and  SM: 

•  Top  level  requirements  for  the  missile  have  not  been  established,  ereating 
potential  performance  risk 

•  The  direetive  to  use  legaey  system  requirements  creates  technieal  risk 

•  Requirements  have  been  ehanged  late  in  the  development  proeess,  ereating 
teehnieal  and  integration  risks 

Eaeh  eoneem  will  be  discussed  individually. 

1.  Top  Level  Requirements 

Top  level  missile  requirements  have  never  been  formally  established  for  the 
JUWE  program  (IWS3  2012).  Error!  Reference  source  not  found,  shows  a  simplified 
diagram  of  the  flow  of  requirements  for  DDG-1000  missile  integration. 
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Figure  28.  DDG-1000  Requirements  Flow  (from  IWS3  2012) 


The  DDG-1000  eontraetor  developed  a  set  of  system  performanee  doeuments 
(SPDs)  whieh  ineluded  system  performanee  speeifieations  (SYS)  and  system 
environment  speeifieations  (SENV).  The  SPDs  were  then  deeomposed  and  alloeated  to 
one  of  the  various  segments  (DBR,  for  example).  The  DDG-1000  eontraetor  did  not 
include  a  missile  segment  in  its  analysis.  Therefore,  the  requirements  decomposition  did 
not  allocate  any  functional  or  performance  requirements  to  the  missile  and  did  not  define 
any  physical  or  logical  interfaces  between  ship  systems  and  the  missile. 

Working  group  meetings  between  the  ship  combat  system  and  missile  programs 
were  held  in  2005  and  the  gap  in  requirements  fiowdown  was  discussed.  A  need  for  pre- 
and  post-launch  interface  control  documents  (ICDs)  to  define  data  link  requirements  was 
agreed  to  but  ship  program  representatives  initially  maintained  that  no  missile 
requirements  were  needed  because  the  missiles  were  assumed  to  perform  as  they  would 
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when  launched  from  an  Aegis  platform  (IWS3  2012).  Further  discussion  of  the 
differences  between  DDG-1000  and  Aegis  requirements  such  as  CONOPs,  threats,  hull 
environments,  and  so  forth  led  to  an  agreement  to  develop  missile  requirements. 
However,  the  first  draft  of  DDG-1000  missile  top  level  requirements  (TLRs)  prepared  by 
the  combat  system  program  office  copied  existing  Aegis  requirements  and  interface 
documents.  Continued  discussions  between  IWS3  (the  JUWL  development  manager)  and 
IWSll  (the  SIPM  for  DDG-1000  at  the  time)  could  not  produce  an  agreement  on  the 
content  and  detail  of  the  missile  TLR.  The  differences  continued  to  center  on  the 
suitability  of  using  existing  Aegis  requirements  in  the  new  DDG-1000  environment;  the 
effort  was  abandoned  in  2007.  The  end  result  was  that  all  legacy  SM  and  ESSM 
requirements  were  considered  “good  enough”  and  were  to  be  used  as-is;  the  only 
requirements  changes  were  those  included  in  the  pre-  and  post-launch  ICDs  to  define  data 
link  requirements  (IWS3  2012).  The  SOWs  presented  to  the  JUWL  prime  contractor  have 
reflected  this  legacy  requirement  and  have  thus  limited  the  level  of  effort  in  the  JUWL 
program. 

0  depicts  the  fiowdown  used  to  achieve  the  current  JUWL  prime  item 
development  specifications  and  gaps  that  still  exist  in  requirements. 
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Note:  APARMsaleIndicatesSourcefor  lew  FtequirementsOriginallyDa/elopedforAPy^R  Based  OorTbatSystems 


Figure  29.  DDG-1000  Requirements  Flow  (from  IWS3  2012) 


The  gaps  in  missile  TLRs  create  uncertainty  of  performance  expectations  and  the 
Navy’s  capacity  to  measure  missile  performance  for  DDG-1000.  It  also  results  in 
technical  risk,  as  JUWL  development  does  not  include  any  mechanism  for  investigating 
or  developing  performance  improvements  in  the  missiles.  The  absence  of  TLRs  is  clearly 
in  contradiction  to  the  emphasis  that  SE  places  on  clear  requirement  definition. 

2,  Legacy  Requirements 

Using  legacy  requirements  produces  risk  in  other  areas  besides  mission 
performance.  DDG-lOOO’s  mechanical,  electrical,  and  electromagnetic  environment  will 
be  different  from  that  of  Aegis  ships.  Potential  for  electromagnetic  interference  (EMI) 
from  other  emitters  on  DDG-1000,  as  well  as  potential  hazards  of  electromagnetic 
radiation  to  ordnance  (HERO)  from  those  emitters,  are  not  addressed  in  the  JUWL 
program  because  legacy  requirements  are  in  place.  Consider  that  the  MER  is  an  entirely 
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new  radar,  operating  in  a  new  frequeney,  with  new  power  levels  and  waveforms.  While 
EMI  or  HERO  issues  are  not  a  eertainty,  they  are  eertainly  a  potential  problem.  And  more 
mundane,  but  no  less  important,  eoneerns  sueh  as  the  vibration  profile  of  the  new  hull 
and  the  differing  proximity  of  the  launehers  (and  thus  missiles)  to  other  hull,  meehanieal, 
and  eleetrieal  (HM&E)  systems  eould  result  in  a  situation  where  a  legaey  requirement  is 
inadequate  or  unsafe. 

This  is  not  to  say  projeetions  of  DDG-1000  environments  are  not  available  or  that 
no  eonsideration  has  been  given  to  these  issues.  Projeetions  and  models  of  other  systems 
are  available.  But  the  JUWL  developer  is  limited  to  providing  a  legaey  missile  with  a 
new  data  link,  and  thus  the  opportunity  to  design  in  response  to  even  the  projeeted 
environments  is  lost.  As  the  lead  ship  in  a  new  elass,  DDG-1000  will  likely  undergo  a 
variety  of  surveys  to  determine  EMI,  HERO  levels,  vibration  profiles,  near-miss  shoek 
levels,  and  so  on.  If  legaey  missile  requirements  are  found  to  be  laeking,  the  entire  DDG- 
1000  program  will  faee  eost  and  sehedule  penalties  in  order  to  “make  up”  the  differenee 
between  legaey  needs  and  DDG-1000  needs. 

3,  Requirement  Changes 

DDG-1000  and  JUWL  have  had  two  signifieant  ehanges  sinee  2009  that  have 
affeeted  eomponent  design.  As  deseribed  in  Chapter  III,  the  2010  program  restrueturing 
following  the  program  Nunn-MeCurdy  breaeh  deleted  the  VSR  from  the  ship.  Some  VSR 
tasks  were  re-alloeated  to  the  MER,  whieh  entailed  radar  resouree  management  ehanges 
and  attendant  software  alterations  in  the  radar  and  the  eombat  system.  These  software 
alterations  impaet  the  MER  radar  timeline.  Timeline  ehanges,  in  turn,  have  the  potential 
to  impaet  missile  performanee.  Eor  example,  the  radar  may  send  fewer  guidanee 
eommands  to  a  missile  in  flight,  redueing  the  aeeuraey  of  the  missile. 

These  radar  timeline  ehanges  have  to  be  analyzed,  modeled,  and  then  installed 
into  the  eombat  system.  Those  models  must  then  be  made  available  to  the  missile 
designers  for  assessment  of  potential  ehanges  in  the  missile.  At  this  time,  the  eombat 
system  eontraetor  has  not  made  a  DDG-1000  speeifie  weapon  eontrol  element  (WCE) 
model  available  for  missile  program  use  (IWS3  2012).  Therefore,  the  JUWL  developer 
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has  proceeded  with  the  assumption  that  DDG-1000  will  be  eonsistent  with  the  Trilateral 
Frigate  Cooperation  (TFC)  software  that  integrated  SM  with  the  APAR  system  (IWS3 
2012).  It  is  also  unelear  if  the  current  radar  model  adequately  refleets  any  changes 
resulting  from  VSR  removal.  The  combat  system  (C/S)  developer  has  not  made  a  full 
radar  model  available  to  JUWL;  they  have  only  provided  statie  radar  data  as  modeled  for 
a  eross-seetion  of  radar  seenarios  (IWS3  2012).  The  entire  system  will  eventually  be 
tested  during  operational  evaluation.  Any  errors  or  diserepaneies  diseovered  at  sueh  a  late 
stage  in  the  program  will  have  major  eost  or  sehedule  ramifieations. 

In  2012,  the  Navy  replaeed  the  SM-2  Bloek  IIIB  missile  with  the  SM-2  Bloek 
IIIA  version.  This  entailed  a  sizeable  design  and  software  ehange  for  JUWL  as  well  as 
ehanges  for  the  eombat  system.  The  internal  arrangement  of  eomponents  among  the  four 
guidanee  seetion  plates  is  different  in  IIIA  missiles  and  IIIB  missiles.  Therefore,  JUWL 
designers  had  to  realloeate  JUWL  eomponents  at  the  eireuit  eard  assembly  (CCA)  level 
and  repeat  their  design  validation  and  verifieation  aetivities.  The  IIIB  missile  also  has 
different  “base”  software  than  the  IIIA  missile  and  JUWL  designers  had  to  re -perform 
their  software  analysis  and  some  software  testing  before  they  eould  import  their  JUWL 
speeifie  software  into  IIIA.  The  software  situation  was  further  eomplieated  by  a 
subsequent  deeision  to  inelude  the  MU  software  update  into  the  IIIA  build-the  JUWL 
software  build  will  be  the  first  IIIA  missile  to  ineorporate  MU. 

The  missile  ehange  also  impacts  the  eombat  system.  IIIA  follows  a  different  flight 
path  than  IIIB  during  the  launch  and  transition  phases  of  flight.  This  flight  path  is 
predieted  by  the  ship’s  eombat  system  so  that  the  eombat  system  ean  aeeurately  direet  the 
radar  to  “eapture”  the  missile  (establish  eommunieations).  The  software  produeing  this 
predietion  is  the  Missile  Trajeetory  Estimator  (MTE).  In  some  cases,  the  differenees 
between  IIIA  and  IIIB  may  be  signifieant  enough  to  impaet  radar  performance.  At  a 
minimum,  the  eombat  system  needs  to  alter  and/or  analyze  the  MTE  to  ensure  that  it 
eneompasses  the  boundaries  of  the  IIIA  flight  profile. 

Both  of  these  ehanges  oeeurred  after  signifieant  program  “run”  time.  Therefore, 

both  efforts  experieneed  sehedule  delays  and  additional  expense.  Both  ehanges  also 

require  coordination  between  the  respeetive  eontraetors  so  that  system  eompatibility  is 
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maintained.  After  signifieant  delays  (which  were  attributable  to  organizational  difficulties 
described  later  in  section  D)  the  combat  system  contractor  has  begun  performing  the 
necessary  analysis  of  the  MTE.  However,  the  C/S  contractor  has  still  not  provided 
complete  and  up-to-date  models  of  the  radar  or  WCE  and  thus  the  JETWE  developer 
continues  development  with  added  risk.  It  is  unclear  if  the  models  do  not  exist,  are  not 
complete,  or  are  not  being  provided  for  some  other  reason. 

C.  INTEGRATION 

Eangford  and  Hitchins  make  persuasive  arguments  that  integration  is  most 
important  part  of  SE  development  (see  Chapter  III).  Integration  produces  emergence, 
which  is  Hitchins’  term  for  the  phenomenon  in  which  a  system  produces  faster, 
expanded,  or  otherwise  “better”  system  performance  than  the  components  of  the  system 
could  achieve  operating  independently. 

This  section  will  examine  DDG-1000  missile  integration  in  terms  of  Eangford’ s 
seven  principles  in  integration.  Annette  Krygiel’s  1999  case  study  entitled  Behind  the 
Wizard’s  Curtain:  An  Integration  Environment  for  a  System  of  Systems  also  provides  a 
number  of  key  integration  insights  gleaned  from  prior  large-scale  integration  projects.  We 
will  also  discuss  other  integration  case  studies  that  reinforce  the  critical  nature  of 
integration  and  illustrate  the  pitfalls  of  reducing  integration  to  merely  something  done 
after  “. .  .analysis  and  design  have  taken  place. . .”  (Hyer  et  al.  1996,  315). 

1.  Integration-Langford’s  Principles 

Eangford’s  Seven  Principles  of  Integration,  listed  in  Appendix  A,  are  an  early 
feature  in  his  text  Engineering  Systems  Integration:  Theory,  Metrics,  and  Methods.  They 
appear  before  he  explains  his  conceptual  construct  of  integration  and  serve  to  remind  the 
reader  that: 

Principles  of  integration  extract  insular  thinking  from  the  quagmire  of 
confusion,  help  guide  decisions  based  on  the  sound  and  the  good  of  a 
particular  situation,  and  present  a  logic  that  creates  an  air  of  confidence.  In 
as  much  as  the  principles  help  others  justify  their  actions,  the  mere  fact  of 
discussing  and  employing  principles  facilitates  decision  fitness  and 
decision  making  throughout  an  organization  (Howard  and  Matheson 
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1984),  reinforces  the  teamness  that  inspires  success,  and  provides  a  top- 

level  perspective  that  retains  purpose,  objectivity,  and  planning  prowess. 

(Langford  2012,  10) 

Langford’s  Seven  Principles  are  the  Principles  of  Alignment,  Partitioning, 
Induction,  Limitation,  Forethought,  Planning,  and  Loss.  While  all  of  Langford’s 
principles  apply  to  any  integration  activity,  this  paper  will  focus  on  those  deemed  most 
relevant  to  missile  integration  on  DDG-1000. 

a.  Principle  One-Alignment 

Langford’s  alignment  principle  states  that  alignment  of  strategies  between  the 
business  enterprise,  key  stakeholders,  and  the  project  results  in  better  outcomes  for 
product  development.  He  states  “. .  .knowing  the  needs  of  the  project  and  how  those  needs 
are  supported  by  the  business  enterprise  and  the  key  stakeholders  is  important  in  keeping 
high-level  visibility  with  the  decision  makers... systems  engineers  place  great  importance 
on  working  with  stakeholders  to  determine  requirements,  verify  that  the  work 
accomplished  satisfies  the  requirements,  and  deliver  to  satisfy  the  user  requirements” 
(Langford  2012,  11).  For  the  DDG-1000  program  in  general,  and  missile  integration  in 
particular,  strategies  have  not  been  aligned. 

The  clearest  example  of  misalignment  is  the  fundamental  disagreement 
concerning  the  appropriateness  of  a  “use-as-is”  decision  for  missile  requirements 
discussed  in  Section  B.  The  author  believes  that  a  use-as-is  requirement  is  prima  facie 
unrealistic;  the  ship’s  missile  launchers,  combat  system,  and  radar  are  all  new 
development  items.  If  there  were  no  differences  involved,  then  no  integration  would  be 
needed.  However,  the  SIPM  clearly  felt  that  similarities  to  existing  systems  (the  APAR 
version  of  ESSM  and  SM)  warranted  the  lower  cost  “use  as  is”  decision;  if  no  significant 
software  or  interface  problems  are  uncovered  before  and  during  operational  testing  their 
opinion  will  be  confirmed.  However,  history  suggests  that  this  will  not  be  the  case. 

In  1996,  the  Ariadne  5  rocket  lost  flight  control  immediately  after  launch  and  was 
completely  destroyed.  The  root  cause  was  found  to  be  failure  to  integrate  and  test  two 
software  elements  in  the  rocket’s  inertial  reference  system  (Madni  2012).  In  1997,  the 
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USS  Yorktown  suffered  a  eomplete  failure  of  its  “smart  ship”  system.  The  system  was 
installed  in  1996  as  a  eompletely  automated  way  to  eontrol  the  engineering  plant;  the  ship 
had  to  be  towed  to  port  after  the  failure.  The  problem  was  traeed  to  inadequate  testing  of 
data  interfaees;  a  zero  inadvertently  entered  into  a  data  field  eaused  a  “divide-by-zero” 
error  whieh  erashed  the  entire  eomputer  network  (Madni  2012).  The  Airbus  A320,  an 
enormous  eommereial  aireraft  projeet,  was  delayed  by  over  two  years  (at  a  eost  of 
$6  billion)  beeause  of  a  simple  semantie  error  on  a  meehanieal  deseription  doeument 
between  a  German  subeontraetor  delivering  wiring  harnesses  and  the  Freneh  faetory 
eonstructing  the  aireraft  (Madni  2012).  Other  high  profile  examples  ean  be  found  in 
NASA’s  Hubble  Space  Telescope  program;  the  Air  Force’s  Theatre  Battle  Management 
Core  System  (TBMCS);  the  F-111  and  A- 10  aircraft  programs;  and  the  Global  Hawk 
UAV  program  (AFIT  2010). 

Misalignment  can  also  stem  from  organizational  differences  and  the  associated 
differences  in  contract  content  and  schedules.  The  responsibilities  for  producing  DDG- 
1000  and  its  combat  system  are  spread  over  three  program  offices  and  three  prime 
contractors;  coordination  of  effort  is  thus  more  difficult.  Further  discussion  of 
organizational  issues  appears  later  in  Section  D. 

b.  Principle  Four-Limitation 

Langford’s  fourth  principle  states  that  integration  can  only  be  successful  to  the 
same  degree  that  the  architecture  is  successful  in  capturing  stakeholder  requirements. 
DDG-1000  missile  integration  faces  a  significant  problem  because  engineers  and 
designers  are  developing  systems  to  integrate  with  other  systems  that  are  likewise  in 
development.  Hence  interfaces,  standards,  and  performance  are  all  subject  to  change. 
This  makes  a  development  program  more  difficult-although  DDG-1000  is  certainly  not 
unique  in  this  respect.  The  absence  of  clear  requirements  discussed  in  Section  B  also  falls 
under  this  principle,  as  an  architecture  cannot  be  truly  developed  until  a  firm  set  of 
requirements  is  in  place  for  the  architecture  to  meet. 

However,  a  second  key  point  Langford  makes  with  the  principle  of  limitation  is 
the  importance  of  the  concept  of  operations  (CONOP)  in  guiding  architecture  developers 
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and  component  designers.  The  CONOP  is  a  eritieal  doeument  that  must  be  kept  eurrent. 
In  the  absenee  of  other,  detailed  speeifieations,  it  provides  designers  a  frame  of  referenee 
to  plan  their  aetivities  and  is  an  invaluable  tool  for  a  design  team  (Langford  2012).  The 
DDG-1000  AW  CONOP  has  not  been  updated  to  refleet  signifieant  program  ehanges.  In 
partieular,  it  does  not  refleet  the  removal  of  the  VSR  and  the  ehange  from  SM2  Bloek  III- 
B  to  III-A.  Given  the  absenee  of  speeifie  requirements,  the  out-of-date  CONOP  further 
eonstrains  the  development  team  beeause  they  do  not  have  a  referenee  doeument  to  refer 
to  when  eondueting  trade  studies  or  planning  for  testing. 

c.  Principle  Five-Forethought 

Langford  states  that  integration  is  a  primary,  key  aetivity-not  an  afterthought 
eonsidered  as  a  result  of  development.  The  following  quotes  are  illustrative  of  his  view 
on  the  subjeet: 

Integration  is  a  daily  foeus,  with  periodie  updates  to  the  integration  plan. 
Integration  is  an  explieit  goal  of  aequisition. . .  (Langford  2012,  19) 

...planning  for  integration  alleviates  problems  that  surfaee  during 
integration  (Langford  2012,  20). 

...often  requirements  are  left  unstated...  at  best,  this  teehnique  of  building 
systems  is  a  guess  at  building  objeets  so  that  performanees  are  met... this 
guess-and-try  again  approaeh  to  integration  is  time-eonsuming  and  dollar- 
expensive.  (Langford  2012,  20) 

DDG-1000  missile  integration  has  fallen  squarely  into  the  trap  of  the  “guess-and- 
try  again”  paradigm. 

2,  Integration-Krygiel’s  “Best  Practices” 

A  1999  DOD  case  study  report  entitled  Behind  the  Wizard’s  Curtain:  An 
Integration  Environment  for  a  System  of  Systems  examined  large  scale  system  of  systems 
integration  in  two  projects:  The  Army’s  Task  Force  XXI  (TF  XXI)  and  the  Defense 
Mapping  Agency’s  (DMA)  Digital  Production  System  (DPS).  The  DPS  was  intended  to 
produce  an  end-to-end  digital  production  system  for  all  of  the  DMA’s  mapping,  charting 
and  geodesy  (MC&G)  products  (Krygiel  1999).  TF  XXI  was  an  Army  project  born  out  of 
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Army  Chief  of  Staff  Gordon  Sullivan’s  efforts  to  fundamentally  re-constitute  the  Army 
after  the  end  of  the  Cold  War.  Sullivan  believed  the  down-sized,  post-Cold  War  Army 
would  need  to  be  expeditionary  in  nature  and  would  need  “...fundamental  ehanges  in 
every  aspect  of  the  Army,  including  structure,  doctrine,  capabilities,  training,  and  tactics” 
(Krygiel  1999,  72).  Such  an  expeditionary  force  would  depend  on  a  “digitized  battlefield” 
with  cutting  edge  information  technology  (IT)  and  command  and  control  (C2)  systems. 
TF  XXI  was  tasked  with  conceptualizing,  testing,  and  selecting  the  C2  and  IT  systems  for 
the  “Army  after  next”  (Krygiel  1999,  74). 

The  case  study  produced  nine  integration  recommendations,  similar  to  Langford’s 
seven  principles.  In  fact,  some  of  the  recommendations  are  nearly  identical.  The 
most  relevant  recommendations  will  be  discussed  here;  the  entire  list  can  be  found  in 
Appendix  B. 


a.  Lesson  1 

Lesson  1  states  that  some  activities  must  occur  before  integration,  including 
developing  the  system  architecture,  developing  and  testing  the  system  constituents,  and 
developing  and  testing  all  interfaces.  Annette  Krygiel,  the  author  of  the  study,  makes  this 
observation  when  discussing  “pre-integration”  activities: 

The  promise  of  plug-and-play  is  a  seductive  one...(t)his  lesson  serves  to 
remind  that  verifying  the  individual  constituent  systems  and  interfaces  and 
certifying  them  for  architectural  compliance  are  not  activities  which 
conclude  the  integration  process  but  rather  are  necessary  to  begin  it.  The 
lesson  is  applicable  to  a  SOS  which  is  a  “new  start”  or  one  which 
incorporates  many  legacy  systems.  (Krygiel  1999,  148) 

While  there  is  a  great  deal  of  debate  regarding  the  appropriateness  of  the  term 
“System  of  Systems”  in  the  greater  SE  community  (see,  for  instance,  Hitchins  [2012]  or 
Stuckenbruck  [2008]),  there  is  no  doubt  that  the  “use  as  is”  requirements  of  the  ESSM 
and  SM  missile  have  resulted  in  a  false  belief  that  integration  is  something  that  is  done  to 
conclude  a  project.  Krygiel  (like  Eangford)  found  that  integration  success  is  greatly 
improved  by  emphasizing  integration  needs  early;  failing  to  do  so  increases  risk. 
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b.  Lesson  4 

Lesson  4  states  “...To  integrate  all  the  systems  of  a  SoS,  plan  for  substantial 
difficulties  and  significant  time  and  resources”  (Krygiel  1999,  158).  The  report  goes  on: 

This  lesson  rejects  outright  the  assumption  of  plug-and-play,  even  while 
presupposing  that  the  appropriate  testing  of  individual  systems  and  their 
interfaces  has  occurred.  It  provides  a  counter-assumption  for  planning 
purposes  based  on  current  experience — that  the  integration  of  a  SOS  is  a 
strenuous  undertaking.  (Krygiel  1999,  159) 

This  is  a  clear  rejection  of  what  are  often  termed  “overly  ambitious  schedules.” 
Even  if  appropriate  pre-integration  activities  have  occurred,  managers  should  still  expect 
to  expend  significant  time  and  resources  on  performing  a  thorough  integration  effort.  The 
resource  needs  increase  with  the  complexity  of  the  systems  to  be  integrated. 

The  JUWL  integration  plan  is  very  ambitious.  The  current  schedule  allows  each 
missile  variant  one  three-to-four  month  period  for  “ground-based”  integration  with  the 
C/S  prior  to  at-sea  flight  testing.  At  this  time,  the  ground  integration  tests  will  be 
performed  with  a  version  of  the  C/S  software  that  will  be  different  than  the  flight  test 
version.  Successful  flight  tests  will  therefore  depend  a  great  deal  on  the  type  and  extent  of 
the  differences  in  the  final  two  DDG-1000  C/S  software  versions  and  the  base  APAR 
software  that  has  directed  JUWL  development.  As  discussed  above,  the  lack  of  radar  and 
WCE  models  has  forced  the  JUWL  developers  to  use  the  original  APAR/ICWI  software 
as  a  basis  for  modeling  and  component  testing. 

Eurthermore,  the  testing  plan  reflects  an  intention  to  “leverage”  the  results  of 
ESSM  (the  first  missile  to  conduct  integration  testing)  into  the  SM  integration  activity. 
The  essentially  means  that  SM  will  not  conduct  the  same  “suite”  of  integration  tests  and 
activities  that  ESSM  does  on  the  assumption  that  what  works  for  ESSM,  given  the 
common  data  link,  will  work  for  SM.  While  this  is  certainly  possible,  it  does  not  allow 
for  the  resolution  of  any  problems  that  may  be  encountered.  In  addition,  the  CVN-78 
program  is  planning  on  “leveraging”  from  DDG-lOOO’s  ESSM  integration,  despite  the 
fact  that  the  DBR  and  C/S  implemented  on  CVN-78  will  not  be  the  same  as  that 
implemented  on  DDG-1000.  The  compressed,  aggressive  integration  schedule  must  be 
considered  a  risk  in  light  of  Krygiel’ s  Lesson  4. 
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c.  Lesson  7 

Lesson  7  contains  the  following  recommendations: 

Certain  common  processes  and  common  infrastructure  in  the  integration 
environment  are  essential  to  manage  a  SOS  integration  successfully.  These 
include  the  following... an  Engineering  Board  with  responsibility  and 
authority  for  identification  and  resolution  of  SOS  issues  and  discrepancies, 
including  the  assignment  of  responsibility  for  correction... establishment 
of  processes  (and  the  automated  means)  for  identification  of  SOS  issues 
and  discrepancies,  their  disposition,  tracking,  and  resolution,  under  the 
management  of  the  Engineering  Board... a  formal  build,  verification,  and 
re-integration  process  for  changes....  (Krygiel  1999,  167-168) 

The  lack  of  a  consistent,  effective  mechanism  to  resolve  technical  issues  between 
the  C/S  and  missile  programs  has  hindered  the  JUWL  effort.  The  missile  program  has 
recognized  many  of  the  potential  technical  and  integration  risks  described  in  this  thesis 
(IWS3  2012).  A  missile  integration  working  group  (MIWG)  was  established  to  analyze 
technical  problems  and  assign  actions  to  resolve  those  problems.  The  MIWG  was 
disbanded  and  restarted  several  times  over  the  course  of  the  program;  the  last  disbanding 
occurred  after  the  2010  restructuring  of  the  entire  DDG-1000  program,  and  the 
subsequent  deletion  of  integration  funding.  This  was  a  particularly  unfortunate  time  to 
eliminate  the  group  as  other  changes  from  the  restructuring,  deletion  of  VSR,  for 
example,  drove  changes  into  the  combat  system. 

Even  if  the  MIWG  and  its  adjunct  group,  the  Missile  Integration  Change  Control 
Board  or  MICCB,  had  remained  in  operation  from  2010-2012,  the  “use-as-is” 
requirement  decision  resulted  in  statements  of  work  that  precluded  design  changes  in 
legacy  hardware.  Such  work  was  deemed  “out  of  scope”  in  contractual  terms.  Therefore, 
even  if  an  integration  problem  is  identified,  such  as  the  MTE  issue  described  earlier,  it  is 
difficult  for  the  program  offices  to  enable  the  contractors  to  perform  the  necessary 
analysis  and/or  corrective  action.  These  delays  only  exacerbate  the  potential  for  last 
minute  “show  stoppers”  to  cause  significant  cost  increases  and  schedule  delays  for  DDG- 
1000. 
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3,  Integration-Other  Best  Practices 

Johns  Hopkins  University’s  Advanced  Physics  Laboratory  (JHU  APL)  assisted 
the  NATO  Sea  Sparrow  Program  Office  (NSPO)  with  planning  and  conducting  the 
integration  of  ESSM  with  the  varying  combat  systems  and  ships  of  the  Sea  Sparrow 
consortium  nations  (Hyer  et  al.  1996).  The  development  effort  began  in  the  mid-1990s 
and  ESSM  began  operational  testing  in  2002. 

One  of  the  key  integration  steps  taken  early  in  the  ESSM  development  effort  was 
the  establishment  of  a  Systems  Integration  IPT.  The  SI  IPT  interfaced  directly  with  the 
ESSM  Integration  IPT  (see  Eigure  30.  ).  The  ESSM  Integration  IPT  was  part  of  the  prime 
contractor’s  IPPD  structure  and  oversaw  numerous  component  IPTs  as  they  performed 
their  design  activities-engineering  analyses,  trade  studies,  and  so  on.  The  SI  IPT 
provided  a  forum  for  the  various  consortium  navies  to  bring  forward  various  issues 
directly  to  the  design  team.  This  was  a  critical  step,  as  ESSM  was  to  be  operable  with  six 
different  combat  systems  on  13  different  classes  of  warship  while  also  maintaining  some 
capacity  for  future  expansions  (Hyer  et  al.  1996,  319). 
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Figure  30.  ESSM  Development  IPTs  (from  Hyer  et  al.  1996,  321) 


The  arrangement  was  intended  to  allow  the  various  nations  an  opportunity  to  pursue 
their  individual  C/S  needs  and  also  allowed  the  program  to  identify  and  develop  common 
interfaces  where  possible.  It  also  gave  the  opportunity  to  influence  design  in  order  to 
mitigate  identified  configuration  issues  (Hyer  et  al.  1996).  This  type  of  arrangement,  as 
noted  in  Section  (2),  has  been  lacking  for  the  DDG-1000  missile  integration  effort. 
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The  Defense  Aequisition  Guidebook  discussion  of  SE  (found  in  Chapter  IV, 
emphasis  added)  states  the  following: 

A  system  should  not  be  acquired  in  isolation  from  other  systems  with 
which  it  associates  in  the  operational  environment... io  that  end,  the 
Program  Manager  and  Systems  Engineer  should  define  intersystem 
interfaces... the  Program  Manager  and  Systems  Engineer  should  also 
actively  pursue  Memoranda  of  Agreement  or  Memoranda  of 
Understanding  (MOA/MOU)  with  companion  programs  regarding 
interfaces,  data  exchanges,  and  advance  notices  of  changes, 
interdependencies  and  schedule  (timing)  that  may  affect  either  program. 

These  agreements  are...  a  means  of  mitigating  the  inherent  risk  in 
planning  to  deliver  a  capability  to  an  anticipated  future  technical  baseline 
when  there  is  uncertainty  that  the  other  programs  are  able  to  maintain 
schedule  and  have  adequate  resources  to  deploy  the  capabilities  as 
planned.  (DAG  2013,  156) 

The  DDG-1000  missile  integration  effort  does  have  MOAs  in  place,  but  as 
described  earlier,  coordination  has  not  always  been  timely  or  productive. 

D,  ORGANIZATION 

Integration  of  large,  complex  systems  is  not  easy.  Establishing  the  correct 
engineering  organization  is  critical  for  success  (Stuckenbruck  2008).  Many  of  the 
concerns  that  DDG-1000  missile  development  has  faced  are  not  unique-all  major 
acquisition  programs  face  the  same  challenges.  The  DOD  routinely  institutes  new  or 
improved  processes  or  organizational  structures  in  an  attempt  to  improve  the  outcomes  of 
the  DAS. 

Weapon  system  acquisition  for  the  Navy  had  traditionally  been  tied  to  platform 
development.  Once  the  weapon  system  was  operational,  the  program  office  shifted  into  a 
primarily  sustainment  mode,  with  the  possibility  of  additional  development  work  to  field 
weapon  improvements.  In  2002,  PEO  IWS  was  organized  for  the  specific  purpose  of 
consolidating  Navy  combat  system  acquisition  from  a  vertical,  platform-centric  approach 
to  a  horizontal,  functional  approach  (Mink  2006).  The  reorganization  was  in  concert  with 
a  new  open  architecture  (OA)  acquisition  approach  for  combat  systems.  The  new  OA 
philosophy  was  a  “...multifaceted  business  and  technical  strategy  for  acquiring  and 
maintaining  National  Security  Systems  (NSS)  as  interoperable  systems  that  adopt  and 
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exploit  open-system  design  principles  and  architecture”  (Emery  2010,  2).  The  express 
goal  of  the  reorganization  was  to  reduce  costs  (Kime  2004;  Syring  2012).  The  cost 
savings  were  to  be  realized  from  “cross  program  efficiencies... multi-year  procurement 
potential... challenging  fixed  and  support  costs... (and)  maximizing  leverage  across 
product  lines  and  programs”  (Deegan  2012). 

Certain  offices  in  PEO  IWS  are  specifically  established  as  Systems  Integration 
Program  Managers  (SIPM);  Eigure  31  shows  the  weapon  acquisition  process  as 
envisioned  during  the  reorganization  of  PEO. 
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Eigure  3 1 .  PEO  IWS  Notional  Acquisition  (from  Emery  2010) 

Several  challenges  remain  for  PEO  IWS  to  achieve  the  type  of  consolidated 
control  that  Assistant  Secretary  of  the  Navy  for  Research,  Development,  and  Acquisitions 
(ASN  RDA)  John  Young  envisioned  at  the  time  PEO  IWS  was  created. 

Eirst,  and  perhaps  most  important,  is  the  fact  that  funding  streams  for  various 
projects  (including  JUWE)  are  not  managed  by  PEO  IWS.  This  clearly  contradicts  the 
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intended  proeess  shown  in  Figure  3 1 .  Shipbuilding  and  Conversion,  Navy  (SCN)  funds 
pay  for  the  development  and  eonstruction  of  all  naval  vessels;  sueh  funds  are  controlled 
by  the  ship  program  office.  JUWL  (for  example)  is  a  development  effort  tied  to  a  new 
class  of  ship;  hence  SCN  funds  pay  for  program  activities.  This  divide  between  weapon 
development  and  funding  inhibits  the  stated  IWS  goal  of  reducing  the  number  of 
baselines  in  the  weapons  inventory  and  creation  of  over-arching  warfare  systems-because 
IWS  cannot  pay  for  them  directly  (Mink  2006).  “Legacy”  weapon  programs  are  funded 
via  Other  Procurement,  Navy  (OPN)  allocations  and  do  not  face  such  challenges. 

The  inconsistency  in  funding  is  indicative  of  a  more  general  problem  concerning 
authority,  responsibility,  and  the  delineation  of  roles  and  responsibilities.  Different 
program  managers  (PEO  Ships,  PEO  IWS,  PEO  Carriers,  and  so  on)  will  clearly  have 
different  opinions  on  programmatic  risk  and  different  priorities  in  program  execution. 
Memorandums  of  Agreement  (MOAs)  are  often  used  to  define  roles  and  responsibilities, 
but  they  are  by  no  means  a  guarantee  of  success.  Eor  example,  ship  program  managers 
(SPM)  often  maintain  configuration  control  for  any  system  being  installed  on  the  hull, 
whether  it  is  combat  system-related  or  not  (Mink  2006).  Some  SPMs  moved  their  combat 
system  related  staff  to  the  IWS  equivalent  office,  while  others  did  not.  Therefore,  some 
SE  tasks  and  organizations  are  undoubtedly  duplicated  at  great  cost.  Eailed  coordination 
of  other  activities  can  have  operational  consequences: 

An  example  of  uncoordinated  ECPs  can  be  seen  when  coordinating 
changes  to  the  Warfare  System  Interface  Diagrams  (WSID).  They  depict 
all  warfare  system  elements  and  their  interconnectivities  for  each  ship  and 
are  used  to  maintain  ship  warfare  system  configurations.  In  the  past, 
requested  WSID  changes  to  aircraft  carriers,  amphibious,  auxiliary.  Coast 
Guard,  and  land-based  test  sites  (EBTS)  have  often  bypassed  the  PEO 
IWS  Warfare  System  Engineers  responsible  for  system  engineering 
coordination  for  these  platforms.  These  uncoordinated  changes,  when 
implemented  aboard  ships,  have  resulted  in  warfare  systems  having 
impaired  operability.  Eixing  these  unexpected  integration  problems 
consumes  resources  that  are  often  unbudgeted. . . .  (Mink  2006) 

IWS  9  has  the  role  of  System  Integration  Program  Manager  (SIPM)  for  surface 
weapons  and  is  “dual-hatted”  as  the  program  manager  for  the  development  of  the  MER. 
The  other  IWS  office  codes  involved  in  DDG-1000  missile  development  (3 A)  and 


84 


eventually  missile  produetion  (3A  and  3D)  ean  be  seen  as  fulfilling  subeontraetor  roles  to 
IWS  9  and  PMS  500.  As  stated,  some  IWS  program  managers  (east  in  the  role  of 
“subeontraetors”  to  the  overarehing  ship  program  manager)  do  not  eontrol  their  funding. 
General  eommunieations  between  the  various  offiees  and  their  respeetive  eontraetors  are 
hampered  by  the  multitude  of  SOWs,  funding  available  to  support  teohnieal  exehanges, 
and  general  proeedural  eumbersomeness.  Methods  to  address  engineering  ehange 
proposals  (ECPs)  vary  from  one  program  to  another  and  ean  be  repetitive,  eostly,  or  more 
seriously,  not  well  established. 

As  with  many  organizational  improvements  and  “eomprehensive”  ehanges, 
failure  to  enaet  the  entire  bundle  of  improvements  ean  result  in  less  improvement  than 
expeeted.  In  some  eases,  ineomplete  ehanges  eould  produee  worse  results  than  the 
original  eonfiguration.  Crities  of  the  establishment  of  PEO  IWS  highlighted  eoneerns 
over  disrupting  sueeessful  programs,  the  size  and  eomplexity  of  the  effort,  and  an  over- 
stretehed  span  of  eontrol  for  IWS  managers  (Kime  2004).  The  last  eleven  years  may  have 
proven  the  erities  to  be  at  least  partially  eorreet. 

While  the  JUWE  effort  for  DDG-1000  does  not  use  the  Eead  Systems  Integrator 
(ESI)  eoneept,  similarities  do  exist  between  the  ESI  eoneept  and  the  eurrent  matrix 
organization  of  PEO  IWS.  The  matrix  organization  of  PEO  IWS  resembles  the  ESI 
eoneept  in  the  faet  that  the  lead  systems  integrator  is  not  the  same  organization 
responsible  for  managing  all  of  the  eonstituent  systems  to  be  integrated.  The 
organizational  strueture  for  DDG-1000  integration  eneounters  many  of  the  same 
problems  that  ESI  programs  eneountered  whieh  are  deseribed  below. 

In  essenee,  the  ESI  eoneept  involves  hiring  a  firm  to  eonduet  the  system 
development  and  program  management  aetivities  that  the  government  traditionally 
performs  (Gully  2003).  It  was  first  employed  in  the  Army’s  Euture  Combat  System  (ECS) 
program.  The  ECS  was  intended  to  develop  a  SoS  that  would  meet  the  Army’s 
modernization  needs  well  into  the  21st  eentury.  The  original  ECS  SoS  arehiteeture 
eonsisted  of  nine  manned  ground  vehieles,  four  unmanned  aerial  vehieles,  four  unmanned 
ground  vehieles,  and  numerous  unmanned  ground  sensors;  all  “networked”  together  by 
multiple  eommunieations  and  C4ISR  systems  (Gully  2003). 
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The  Army  selected  the  LSI  approach  for  the  PCS  because  it  felt  it  did  not  have  the 
expertise  to  manage  the  development  and  integration  of  over  20  separate  supporting 
programs.  The  Army  also  felt  it  did  not  have  the  time  to  develop  such  an  organization 
because  of  FCS’s  aggressive  timeline  and  the  cumbersome  federal  personnel  system 
(Flood  and  Richard  2006).  Hence  the  Army  contracted  an  industry  team  to  perform  the 
LSI  role.  Boeing  and  Science  Applications  International  Corporation  (SAIC)  were 
selected  as  the  LSI. 

The  LSI  arrangement,  while  theoretically  sound,  encountered  immediate 
problems.  Most  problems  can  be  grouped  into  two  categories:  “cultural”  and 
“procedural.”  The  cultural  problems  arose  from  the  new  duties  and  responsibilities 
assigned  to  participants  in  the  system.  Government  program  personnel,  used  to  authority 
and  responsibility,  were  relegated  to  oversight  tasks.  This  often  led  to  adversarial  or 
strained  relations  when  the  LSI  made  programmatic  decisions  counter  to  the  program 
office’s  desires.  The  LSI,  in  turn,  felt  that  the  Army  was  not  prioritizing  the  FCS  in 
comparison  to  other  programs  and  also  felt  that  many  in  the  Army  opposed  the  entire 
network-centric  concept.  This  doubtless  led  the  LSI  to  discount  the  Army’s  opinions  on 
the  many  issues  raised  in  the  early  stages  of  concept  development  (Flood  and  Richard 
2006). 

Relations  between  the  LSI  and  the  various  subcontractors  were  also  strained,  as 
many  “subs”  believed  the  LSI  was  ignoring  their  concerns  or  otherwise  maneuvering  to 
win  future  production  and  development  contracts  for  architecture  components  under 
consideration  (Flood  and  Richard  2006,  364).  Congress  balked  at  the  loss  of  monetary 
control  over  FCS-the  LSI  effort  was  a  single  program  element  (PE)  in  the  Army  budget 
and  thus  the  LSI  had  much  greater  control  over  funding  than  a  traditional  program 
manager.  Congress  was  also  concerned  with  the  incentive  fee  structure  of  the  contract; 
various  reports  pointed  out  that  the  LSI  could  receive  some  or  all  of  its  substantial 
incentive  fees  even  if  the  Army  never  took  delivery  of  a  single  FCS  component  (GAO 
2007). 
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Procedural  problems  also  haunted  the  PCS  program.  Program  partieipants  in  both 
industry  and  government  universally  stated  that  the  PCS  contraets  were  not  speeific 
enough  to  give  the  government  a  means  to  enforce  its  oversight  role.  There  were  no 
mechanisms  in  place  to  resolve  requirements  disagreements,  for  example,  and  the  LSI 
made  these  programmatie  deeisions  by  default.  The  proeesses  in  plaee  for  integration  and 
lower-level  requirement  eoordination  were  slow  and  eumbersome.  Many  subeontraetors 
and  government  personnel  felt  that  their  eoneems  were  “buried”  by  the  LSI,  or  at  the 
least  were  not  heard  at  the  appropriate  level  (Plood  and  Riehard  2006,  367).  Indeed,  an 
industry  “whistle  blower”  resorted  to  posting  video  explanations  of  his  eoneerns  with  the 
program  on  the  Internet  when  he  felt  he  could  not  gain  traction  with  anyone  in  the  LSI 
hierarehy  (Gansler  2009). 

The  PCS  was  the  target  of  considerable  Congressional  scrutiny  and  was  re¬ 
organized  three  separate  times  before  finally  being  eancelled  in  2009;  the  “subsystems” 
that  had  not  been  eaneelled  were  relegated  to  various  other  program  offiees. 

The  PCS  is  not  the  only  example  of  the  LSI  eoneept  “gone  wrong.”  The  Coast 
Guard’s  “Deepwater”  program  was  a  similar,  large  seale  development  designed  to 
produee  a  networked  SoS  of  cutters,  patrol  boats,  aircraft,  and  unmanned  vehicles.  The 
LSI  in  this  ease  was  a  joint  effort  of  Loekheed  Martin  and  Northrop  Grumman.  The  first 
eontraet  was  awarded  in  2002.  By  2007,  the  Coast  Guard  took  over  the  LSI  role  beeause 
of  pereeived  poor  performance,  delays,  and  eost  overruns.  In  subsequent  years, 
signifieant  eomponents  of  the  original  SoS  were  eaneelled,  including  the  various 
unmanned  aerial  vehieles  and  several  of  the  proposed  surfaee  ships  and  eraft.  The 
Deepwater  project,  much  like  PCS,  was  finally  eaneelled  in  2012  with  remaining 
development  assigned  to  speeifie  program  offiees  (Lipowiez  2013). 

The  PCS  and  Deepwater  programs  were  so  poorly  regarded  that  in  2008  Congress 
passed  legislation  prohibiting  any  future  aequisition  program  from  utilizing  the  LSI 
approaeh  (Gansler  2009). 

The  funding  and  eommunication  difficulties  experieneed  by  PEG  IWS  when 
working  with  other  program  exeeutive  offices  is  similar  to  those  experieneed  by  PCS  and 
Deepwater.  PEO  IWS  features  an  internal  matrix  organization  that  is  speoifieally 
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designed,  like  any  matrix  organization,  to  balanee  the  needs  between  integration  and 
speeialization  (Stuckenbruek  2008,  211).  However,  implementing  an  effeetive  matrix 
requires  eonsistent  effort  towards  fostering  effeetive  management  interfaees  and  a  great 
deal  of  planning  and  effort  (Linnebuck  1988).  Unfortunately,  PEO  IWS  does  not  merely 
have  to  manage  its  internal  organization;  it  must  also  interfaee  with  program  elements 
beyond  its  eontrol. 

E,  SUMMARY 

Missile  integration  for  DDG-1000  is  a  seemingly  straightforward  teehnieal  effort. 
However,  in  the  eontext  of  systems  engineering,  “straightforward”  does  not  neeessarily 
mean  “easy.”  For  DDG-1000,  missile  integration  has  been  ehallenging  beeause  of 
requirement,  integration,  and  organizational  issues. 

Major  elements  of  the  program  did  not  agree  on  the  importanee  of  establishing 
new  top  level  requirements  for  DDG-lOOO’s  intended  missiles.  Instead  the  deeision  was 
made  to  use  legaey  missile  requirements  for  every  aspeet  of  the  missile  exeept  the  new 
data  link.  This  introdueed  substantial  risk  beeause  the  unspeeified  operational  needs  and 
unknown  hull  environments  of  DDG-1000  may  not  be  satisfied  by  legaey  missile 
speeifieations. 

Integration  has  also  been  ehallenging.  Despite  substantial  evidenee  from  prior 
programs  and  over-arehing  guidanee  from  the  DOD,  integration  appears  to  be  an 
afterthought  for  many  programs,  ineluding  the  missile  eomponents  of  the  DDG-1000 
program.  Eaeh  missile  variant  has  approximately  three  months  allotted  to  conduct  all  of 
the  integration  activities  needed  with  the  radar  and  combat  system  before  the  missiles  are 
scheduled  for  their  first  test  firings.  Scheduling  initial  integration  activities  so  late  in  a 
program  increases  cost  and  schedule  risk  because  unanticipated  problems  will  be  harder 
to  correct.  Changing  requirements  late  in  the  program  also  increases  risk,  for  similar 
reasons.  The  program  must  also  have  a  robust  method  for  assessing  and  rectifying 
technical  integration  challenges  that  are  identified  by  designers. 
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Organization  structures  can  influence  both  requirement  and  integration 
challenges.  In  the  case  of  PEO  IWS,  its  matrix  organization  would  be  ideal  for  this  sort  of 
development  effort  if  it  was  also  funded  adequately  to  perform  its  integration  manager 
role  and  had  complete  control  of  the  development  funds  dedieated  to  its  programs.  Any 
large  scale  integration  effort  faces  ehallenges  in  communieation  and  coordination;  the 
establishment  of  a  robust  “Systems  IPX”  or  engineering  ehange  control  board  is  critical  to 
resolving  technical  issues  as  they  arise. 
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VI.  FINDINGS,  CONCLUSIONS  AND  RECOMMENDATIONS 


A,  FINDINGS  AND  CONCLUSIONS 

The  strategic  situation  that  gave  rise  to  the  early  DDG-1000  concept  of  a  land- 
attack  destroyer  changed  rapidly  as  the  United  States  reacted  to  the  post-Cold  War  world. 
The  first  reaction  to  the  collapse  of  the  Soviet  Union,  when  combined  with  the  near- 
simultaneous  technological  triumph  of  the  First  Gulf  War,  produced  the  “Revolution  in 
Military  Affairs”  paradigm.  The  RMA  emphasized  technical  dominance  and  the  DDG- 
1 000  was  deliberately  intended  to  feature  “next  generation”  technology  in  every  aspect  of 
the  ship.  This  was  in  direct  contrast  to  the  Navy’s  longstanding  experience  of  adding  one 
or  two  emerging  technologies  to  known  hull  forms-perhaps  best  exemplified  by  the 
commonality  and  incremental  growth  between  the  FFG-7,  DD-963,  CG-47,  and  DDG-51 
classes.  Ironically,  the  Navy  submarine  force  had  just  experienced  the  perils  of  inserting 
too  many  new  technologies  (and  the  concomitant  risks  and  cost)  into  its  next  generation 
platform  (the  Seawolf  class);  many  of  the  issues  that  affected  Seawolf  are  replicated  in 
Zumwalt. 

The  changing  strategic  situation  resulted  in  requirement  changes  and  cost  growth 
(as  the  numbers  of  intended  ships  were  repeatedly  reduced).  The  most  consequential 
change  for  missile  development  was  the  deletion  of  the  VSR  from  the  ship.  This,  in  turn, 
drove  changes  into  the  MFR-particularly  in  the  areas  of  radar  timeline  and,  potentially, 
the  concept  of  operations.  The  impacts  of  those  changes  have  yet  to  be  fully  identified 
and  tested. 

The  drive  to  use  existing  missiles  in  DDG-1000  led  to  a  “use  as  is”  decision 
regarding  top-level  missile  requirements  for  the  ship.  Only  new  requirements  for  a  data 
link  were  generated.  All  other  missile  requirements  (performance,  safety,  mechanical  and 
electrical  interfaces,  and  so  on)  remain  unchanged  from  the  missiles’  Aegis  system 
requirements.  The  “use  as  is”  decision  does  not  change  the  fact  that  the  DDG-1000 
environment  will  not  be  identical  to  an  Aegis-equipped  vessel.  DDG-1000  will  have  a 
new  radar,  new  combat  system,  new  launcher,  new  hull  form,  and  new  mission-all 
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distinct  from  legacy  Aegis  ships.  Therefore,  the  program  aecepted  integration  and 
(ultimately)  performance  risk  by  not  allowing  engineers  to  identify  and  address  potential 
teehnieal  risks  early.  These  risks  were  eompounded  by  scheduling  a  late,  aggressive 
integration  and  test  sehedule  that  eounted  on  “leveraging”  successful  test  results  between 
ESSM  and  SM.  This  plan  will  only  work  if  the  initial  tests  are,  indeed,  sueeessful. 

Organizational  obstaeles  exaeerbated  funding,  requirement  and  engineering 
difficulties.  All  development  items  for  DDG-1000,  ineluding  the  DBR  and  JUWL,  are 
funded  via  SCN  appropriations.  The  missile  integration  program  managers  do  not  have 
control  of  this  funding  and  are  at  the  merey  of  someone  else’s  sehedules,  eontraet  eriteria, 
and  priorities.  The  2011  shut-down  and  re-start  of  the  JUWL  development  program  is  a 
prime  example  of  the  eonsequenees  of  a  fraetured  ehain  of  eommand  and  funding 
proeess.  This  situation  is  preeisely  what  the  2002  reorganization  of  the  PEO  strueture  was 
intended  to  reetify-but  that  intended  system  has  not  been  fully  realized. 

Organizational  structure  eomplieates  integration  and  engineering  eooperation. 
There  has  not  been  a  eonsistent,  empowered  government  deeision-making  body  eapable 
of  resolving  teehnieal  issues  identified  in  the  respeetive  programs.  Therefore,  teehnieal 
risks  are  eontinually  “earried  forward”  instead  of  being  resolved  at  the  earliest  possible 
stage. 

In  the  introduetion,  two  overarehing  question  were  raised  eoneerning  missile 
development  for  the  DDG-1000  program.  DDG-1000  has  yet  to  be  launehed  and  no 
missiles  have  been  fired  from  the  ship.  Therefore,  it  may  be  premature  to  definitively 
state  any  lessons  learned  from  failures  or  sueeesses.  However,  the  thesis  has  elearly 
identified  risks  that  were  aceepted  by  the  program  that  appear  to  be  unwarranted  given 
prior  case  studies  and  systems  engineering  standards.  The  following  table  summarizes 
those  risks  and  potential  impaets  to  the  program. 
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Table  5.  Integration  Issues  and  Consequences 


Issue 

Potential  Consequence 

No  top  level  requirements 

Failure  to  meet  performance  needs;  safety  risks 

Late  requirement  changes 

Costly  rework,  schedule  delays 

“Use  as  is”  decision 

Late  identification  of  integration  problems, 

inadequate  architecture  design 

Poor  organizational  construct 

Poor  engineering  change  and  integration 

control,  slow  response  to  new  issues 

All  of  the  issues  have  been  catalogued  and  discussed  in  academic  sources, 
systems  engineering  documents,  and  government  publications.  The  results  of  the  thesis 
verify  the  guidelines  put  forth  by  Langford,  Krygiel,  and  others.  Numerous  briefings  and 
studies  highlight  the  recurring  themes  of  inadequate  and  changing  requirements,  poor 
organizational  design,  and  underestimates  of  integration  cost  and  time  requirements.  Why 
DOD  programs  continue  to  repeat  errors  of  this  type  is  a  question  that  will  continue  to 
face  program  managers  and  government  executives  and  deserves  continuing  examination. 

B,  RECOMMENDATIONS 

The  DDG-1000  program  in  general,  and  missile  integration  for  DDG-1000  in 
particular,  face  numerous  challenges  that  seem  to  be  endemic  to  the  defense  acquisition 
system.  All  of  the  issues  described  in  this  paper  have  affected  numerous  development 
projects  in  not  only  all  four  services  of  the  DOD,  but  also  in  other  government  projects 
and  even  in  commercial  industry. 

Congress,  the  Executive  branch,  and  the  DOD  have  taken  steps  to  rectify  these 
systemic  problems,  but  the  complexity  of  the  systems  being  acquired  and  the  diverse, 
interwoven  organizations  needed  to  conduct  the  acquisition  process  continues  to  stymie 
reform  efforts.  These  problems  are  likely  to  continue,  and  possibly  worsen,  as  the  DOD 
likely  faces  near-stagnant  growth  or  even  a  reduction  in  future  budgets.  Integration  is 
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commonly  one  of  the  first  areas  to  see  funding  redueed  in  a  projeet.  Many  managers  still 
eonsider  it  a  “niee  to  have”  or  eonsider  integration  another  name  for  testing  (NDIA 
2003). 

It  is  eritieal  that  Congress,  the  president,  and  the  DOD  not  abandon  efforts  to 
improve  the  aequisition  system.  The  following  recommendations,  based  on  the  principles 
and  lessons  learned  described  earlier,  would  help  mitigate  the  issues  diseussed. 

First,  the  DOD  must  continue  to  emphasize  and  enable  the  application  of  systems 
engineering  early  in  the  acquisition  cycle.  Systems  engineering  as  a  diseipline  is  intended 
to  resolve  many  of  the  engineering  development  challenges  deseribed  in  this  paper.  Clear 
definition  of  user  needs,  thorough  examination  of  alternate  means  to  meet  needs,  and 
eomplete  translation  of  needs  into  elear  requirements  are  the  hallmarks  of  the  early  steps 
of  systems  engineering.  This  reeommendation  is  in  keeping  with  Langford’s  principle  of 
emphasizing  integration  aetivities  early.  Integration  is  what  provides  the  benefit  of  the 
system,  and  thus  it  should  be  emphasized  eontinuously.  The  benefits  of  applying  systems 
engineering  early  have  been  highlighted  in  numerous  studies,  ineluding  the  IEEE  study 
deseribed  in  Chapter  IV  (Elm  and  Goldenson  2012). 

Eor  JUWL,  a  eritieal  early  deeision  to  use  ESSM  and  SM  “as  is”  (with  the 
exeeption  of  the  new  X-band  data  link)  produeed  substantial  risk  that  has  been  earned 
forward  through  the  program.  Sueh  a  deeision  would  likely  not  have  been  made  under 
serutiny  from  a  vigorous  SE  analysis.  The  missiles  are  required  to  interaet  with  a  great 
deal  more  than  just  the  radar  system  after  launeh.  They  must  be  eompatible  with  their 
mechanieal  and  eleetrieal  environment.  Missile  performance  must  meet  the  performanee 
requirements  explicitly  established  for  the  eombat  system  or  derived  from  the  CONOP. 
An  SE  analysis  would  also  have  examined  the  expected  life  cyele  of  the  missiles  and 
expected  number  to  be  produeed,  and  may  have  identified  the  SM-2  Bloek  III-B 
inventory  issue  that  led  to  the  2012  deeision  to  ehange  from  Bloek  III-B  to  Bloek  III-A. 

Applieation  of  systems  thinking  and  the  SE  proeess  ean  avoid  situations  sueh  as 
the  one  DDG-1000  now  faees.  The  DOD  has  aeknowledged  this  faet  for  over  twenty 
years  and  has  taken  signifieant  steps  to  install  systems  engineering  rigor  into  weapon 
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acquisition.  One  avenue  of  further  researeh  suggested  by  this  paper  is  an  examination  of 
why  sueh  steps  have  not  produeed  more  signifieant  improvements  in  weapon  aequisition 
outeomes.  A  quiek  eomparison  of  the  NDIA’s  top  five  SE  issues  from  2003  to  2013 
shows  eonsistent  themes  of  poor  requirement  formulation,  poor  ehange  eontrol, 
inadequate  user  involvement,  and  late-ehanging  requirements  (NDIA  2003;  NDIA  2008; 
NDIA  2013).  There  is  also  evidenee  that  aequisition  programs  do  not  perform  the 
aetivities  they  are  direeted  to  implement  (Masters  2008,  8).  The  2010  QDR  deseribed 
four  issues  faeing  the  DOD  that  require  “imperative”  reforms;  one  of  those  areas  was 
aequisition  (OSD  2010).  The  aequisition  eoneerns  were  further  deseribed  as: 

First,  the  requirements  for  new  systems  are  too  often  set  at  the  far  limit  of 
eurrent  teehnologieal  boundaries... (T)he  Department  and  the  nation  ean 
no  longer  afford  the  quixotie  pursuit  of  high-teeh  perfeetion  that  ineurs 
unaeeeptable  eost  and  risk.  Nor  ean  the  Department  afford  to  ehase 
requirements  that  shift  or  eontinue  to  inerease  throughout  a  program’s  life 
eyele... 

Seeond,  the  Pentagon’s  aequisition  workforee  has  been  allowed  to 
atrophy,  exaeerbating  a  deeline  in  the  eritieal  skills  neeessary  for  effeetive 
oversight.  For  example,  over  the  past  ten  years,  the  Department’s 
eontraetual  obligations  have  nearly  tripled  while  our  aequisition  workforee 
fell  by  more  than  10  pereent...(T)here  remains  an  urgent  need  for 
teohnieally  trained  personnel — eost  estimators,  systems  engineers,  and 
aequisition  managers — to  eonduet  effeetive  oversight... 

Third,  our  system  of  defining  requirements  and  developing  eapability  too 
often  eneourages  relianee  on  overly  optimistie  eost  estimates...  In  order 
for  the  Pentagon  to  produee  weapons  systems  effieiently,  it  is  eritieal  to 
have  budget  stability — but  it  is  impossible  to  attain  sueh  stability  in 
DOD’s  modernization  budgets  if  we  eontinue  to  underestimate  the  eost  of 
sueh  systems  from  the  start... (T)here  are  too  many  programs  under  way. 

We  eannot  afford  everything  we  might  desire;  therefore,  in  the  future,  the 
Department  must  balanee  eapability  portfolios  to  better  align  with  budget 
eonstraints  and  operational  needs,  based  on  priorities  assigned  to 
warfighter  eapabilities...(OSD  2010,  76) 

These  are  the  same  problems  identified  in  a  host  of  previous  studies.  Why  have 
earlier  improvements  efforts  failed?  Identifieation  of  underlying  issues  that  are  stymying 
the  efforts  of  OASD-SE  and  others  eould  eontribute  to  better  aequisition  performanee  in 
the  future. 


95 


Second,  programs  must  require  a  thorough  systems  architecture  analysis  and 
requirements  flowdown  for  legacy  systems  integrated  with  new  systems.  This 
recommendation  is  an  amplification  of  a  portion  of  the  early  SE  process  recommended 
above.  The  emphasis  is  necessary  because  the  use  of  a  legacy  system  as  part  of  a  new 
system  raises  additional  opportunities  for  a  loss  of  SE  rigor.  The  requirements  flowdown 
process,  by  which  higher  system  level  requirements  are  examined  and  assigned  to  lower 
level  system  components,  is  a  key  activity  in  early  systems  engineering.  It  ensures  that  all 
requirements  are  accounted  for  in  the  system  design  (NASA  2007).  It  also  provides  an 
opportunity  to  examine  the  adequacy  of  the  requirements.  If  the  requirement  does  not 
clearly  state  the  need  to  be  met  then  the  requirement  will  not  be  easily  assigned  to  a 
subsystem.  This  mismatch  indicates  a  need  to  revise  or  rework  the  requirement 
(Blanchard  and  Eabrycky  1998). 

As  we  have  discussed,  program  offices  face  perennial  difficulties  in  maintaining 
cost  and  schedule  targets.  Incorporation  of  a  legacy  system,  which  in  theory  was  already 
subjected  to  a  rigorous  requirements  analysis,  gives  rise  to  a  temptation  to  save  time  and 
money  by  not  performing  a  thorough  analysis  of  the  legacy  system  in  its  new  application. 
Such  a  thought  process  is  evident  when  considering  the  fundamental  disagreement 
between  the  responsible  program  offices  on  the  necessity  of  such  requirements  for 
ESSM/SM/JUWL.  The  disagreement  points  to  a  need  to  develop  an  informed  analysis  of 
the  issue. 

The  systems  engineering  “method”  tells  us  that  requirements  must  be  analyzed 
and  flowed  down  in  any  development  project,  even  one  utilizing  existing  technology 
(Eangford  2012;  Blanchard  and  Eabrycky  1998).  Even  if  one  allows  that  such  an  analysis 
was  done  for  DDG-1000  and  JUWL,  the  analysis  did  not  go  far  enough  into  the  details  of 
integration.  It  stopped  at  a  high  level  and  claimed  that  “use  as  is”  requirements  were 
sufficient. 

Previous  case  studies  have  highlighted  the  difficulty  of  integrating  even  when 

such  an  analysis  has  been  performed — programs  must  be  prepared  to  find  unanticipated 

integration  issues  (Krygiel  1999,  Eangford  2012).  Adapting  a  legacy  system  for 

modification  and  introduction  into  a  new  system  cannot  be  an  excuse  to  forego  the 
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critical  initial  steps  of  systems  engineering,  even  if  the  program  is  “leveraging”  the 
benefits  of  integrating  a  legaey  system.  As  Krygiel  noted  in  her  study,  “plug-and-play” 
ean  be  a  seduetive  notion  that  all  too  often  fails  to  deliver  on  its  promises. 

On  a  related  note,  we  should  eonsider  the  logieal  implieations  of  using  legaey 
weapons  with  new  sensor  systems  (or  viee  versa).  Consider  that  DDG-1000  was  elearly 
intended  to  produee  substantial  performanee  improvements  in  all  warfare  areas  in 
eomparison  to  the  existing  Aegis  system.  The  DBR  was  intended  to  traek  more  targets 
with  greater  preeision,  engage  more  targets  simultaneously,  and  so  on.  Legaey  weapons 
(SM  and  ESSM)  have  performanee  envelopes  traeed  to  their  requirements  when  used 
with  legaey  sensors.  If  we  are  developing  a  new  sensor  to  expand  our  sensor  performanee 
envelope,  have  we  done  analysis  to  prove  that  our  legaey  weapons  have  a  eomparable 
expansion  of  their  performanee  margin?  In  other  words,  DBR  may  be  a  signifieant 
improvement  from  Aegis — but  such  improvements  may  not  be  realized  without 
eoneurrent  weapon  advaneement.  Again,  early  applieation  of  the  SE  proeess  should 
answer  these  questions.  Eurthermore,  we  should  eonsider  the  neeessity  for  deploying  a 
next-generation  air  defense  system  on  a  platform  originally  intended  for  a  primarily  land 
attaek  role.  Would  it  have  been  feasible  to  deploy  DDG-1000  with  the  Aegis  system  and 
save  the  DBR  development  for  the  CG-X?  Sueh  a  plan  would  have  been  in  keeping  with 
the  Navy’s  praetiee  of  deploying  only  a  few  new  teehnologies  on  eaeh  new  warfare 
platform. 

Third,  place  all  weapon  system  development  funding  under  the  control  of  PEO- 
IWS.  The  2003  NAVSEA  reorganization  of  its  PEG  strueture  was  intended  to  plaee  all 
weapon  system  aequisition  in  the  eontrol  of  the  newly  formed  PEG  IWS  organization 
(Kime  2004;  Mink  2006).  This  has  not  happened  in  all  eases.  The  vagaries  of  the  PPBE 
system,  the  Congressional  budgeting  proeess  (and  all  of  its  politieal  influenees),  and 
various  statutes  regarding  federal  outlays  all  combine  to  produee  a  fractured  funding 
system.  In  the  ease  of  JUWL,  funding  flows  from  PMS-500,  the  program  offiee 
responsible  for  overall  DDG-1000  ship  proeurement.  Tying  weapons  eomponent 
development  to  new  ship  eonstruetion  (partieularly  new  elass  eonstruetion)  inereases  the 
organizational  diffieulties  deseribed  in  Chapter  V.  Additional  layers  of  eoordination  and 
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approval  result  in  increased  delays.  The  responsibility  to  plan  development,  budget  for 
development,  and  execute  to  that  budget  should  reside  with  program  manager  closest  to 
the  effort.  A  corollary  to  this  recommendation  is  the  need  to  adequately  fund  and  staff  the 
integration  manager  of  the  project.  The  integration  manager  has  the  most  critical  piece  of 
the  development  effort,  and  should  be  the  driver  of  the  development  effort  (even  if  it 
must  cross  program  office  boundaries).  This  step  would  also  allow  the  integration 
manager  to  adequately  fund  the  engineering  change  control  board  or  integration  IPT  as 
described  by  Hyer  et  al.  (2006)  and  Krygiel  (1999).  It  would  also  allow  the  weapon 
program  office  to  organize  the  change  process  to  reflect  the  process  used  in  other  weapon 
programs  rather  than  adopting  the  hull-centered  ShipMain  and  SPM  process  (Mink  2006, 
37). 

The  great  success  of  the  Aegis  weapon  system  is  contributable  in  great  measure  to 
the  fact  that  Admiral  Meyer  and  his  staff  were  the  single  focus  for  all  aspects  of  the 
program — not  only  sensor,  weapon,  and  doctrine  development  but  also  logistics  planning, 
maintenance  support,  and  so  on.  Evidence  of  this  can  be  seen  in  the  fact  that  when 
portions  of  the  program  were  removed  from  this  “central”  control  program  performance 
suffered  (LaPointe  2013).  The  most  noticeable  effect  was  worsening  material  readiness  of 
Aegis  combat  systems  and  deteriorating  levels  of  expertise;  however  Aegis  software 
improvements  to  support  BMD  also  suffered  delays  and  previously  unseen  integration 
issues  (Harvey  2012).  The  acquisition  system  must  reflect  the  military  adage  that  states 
that  authority  must  be  commensurate  with  responsibility. 

C.  FINAL  THOUGHTS 

All  of  the  recommendations  listed  above,  and  many  other  efforts  already 
underway  in  the  DOD  to  “fix”  the  acquisition  system,  require  time  and  money.  Given  the 
fact  that  budgets  will  likely  shrink  or  stagnate  over  the  next  decade,  one  could  be 
pessimistic  about  the  chances  of  success  even  if  we  accept  the  necessity  of  the  corrective 
actions.  Despite  the  general  perception  of  waste  and  failure  in  acquisitions,  there  have 
been  successful  programs  in  recent  years.  The  Virginia-class  submarine  and  the  MRAP 
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program  come  to  mind.  It  does  seem  that  sueeess  has  become  the  exeeption,  however, 
and  the  DOD  (or  perhaps  more  accurately  the  nation)  eannot  maintain  the  status  quo. 

Removing  the  government  from  the  management  role  (as  in  the  Army’s  PCS  and 
the  Coast  Guard’s  Deepwater  projeet)  is  not  the  answer.  Instead,  emphasis  should  be 
plaeed  on  fully  realizing  the  many  initiatives  implemented  in  the  past.  For  example,  if  the 
Navy  intends  PEO  IWS  to  develop  eombat  systems  via  an  open  arehitecture  model  that 
ean  reduee  ineffieiencies  and  improve  eommonality,  it  should  plaee  all  funding  for 
weapon  development,  sustainment,  and  improvement  under  the  IWS  umbrella.  PEO  IWS 
is  also  a  logieal  home  for  all  technieal  and  risk  deeisions  to  be  made  coneerning  both  new 
and  fielded  weapons.  This  would  have  removed  many  of  the  difficulties  faeed  by  the 
JUWE  program,  partieularly  as  they  relate  to  integration.  The  DOD  knows  it  must  foree 
systems  engineering  rigor  into  the  early  phases  of  aequisition-reeent  emphasis  on  early 
teehnieal  reviews  and  the  ereation  of  Configuration  Steering  Boards  (CSB)  for  ACAT  I 
programs  affirm  this — and  those  efforts  must  eontinue. 

The  Navy  has  eonsolidated  authority  in  other  programs.  The  Navy  nuelear  power 
program  and  the  Aegis  eombat  system  program  have  produeed  robust  systems  that  have 
performed  at  a  eonsistently  high  level  for  many  years.  Both  of  these  programs  had  strong 
leadership,  but  they  were  also  given  all  the  tools  neeessary  to  meet  their  goals.  Perhaps  it 
is  time  to  establish  this  eonsolidated  control  mentality  into  all  weapons  system 
aequisition  programs. 
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APPENDIX  A.  LANGFORD’S  SEVEN  PRINCIPLES 


1 .  Principle  of  Alignment 

Alignment  of  strategies  for  the  business  enterprise,  the  key  stakeholders,  and  the  projeet 
results  in  better  outeomes  for  produet  or  serviee  development. 

2.  Prineiple  of  Partitioning 

Partitioning  of  objeets  ean  ereate  traetable  problems  to  solve  if  and  only  if  boundary 
eontiguity  is  aehieved. 

3.  Prineiple  of  Induetion 

Induetive  reasoning  should  guide  integration  management  and  recursive  thinking. 

4.  Prineiple  of  Limitation 

Integration  is  only  as  good  as  arehiteeture  eaptures  stakeholder  requirements. 

5.  Prineiple  of  Forethought 

Integration  is  a  primary,  key  aetivity,  not  an  afterthought  eonsidered  as  the  result  of 
development. 

6.  Prineiple  of  Planning 

Integration  planning  is  predieated  on  pattern  seheduling  (lowest  impaet  on  budget), 
network  seheduling  (determinable  impaet  on  budget),  and  ad  hoe  seheduling 
(undetermined  impaet  on  budget). 

7.  Prineiple  of  Loss 

When  two  objeets  are  integrated,  both  objeets  give  up  some  measure  of  autonomous 
behavior. 
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APPENDIX  B.  INTEGRATION  LESSONS  LEARNED  FROM 
“BEHIND  THE  WIZARD’S  CURTAIN” 


Lesson  1 

Certain  activities  should  precede  a  SOS  integration.  These  include: 
defining  the  SOS  architecture; 
developing  and  testing  the  individual  system 
constituents  of  the  SOS; 

developing  and  testing  the  interfaces  between  and  among  the  individual  systems 
of  the  SOS; 

independently  certifying  compliance  with  the  SOS  architecture. 

Lesson  2 

Use  early,  incremental,  and  iterative  integration  to  achieve  a  SOS. 

Lesson  3 

The  testing  strategy  for  the  integration  of  a  SOS  requires: 

an  agreed-to  plan  and  process  for  testing,  based  on  a  risk  assessment; 

a  suite  of  activities  representative  of  the  operational  requirements  of  the 
mission  the  SOS  supports; 

the  exercising  of  a  full  spectrum  of  the  SOS  activities  (end-to-end)  by 
operators,  using  the  actual  constituent  systems  of  the  SOS  or  at  least  a  core 
SOS. 

Lesson  4 

To  integrate  all  the  systems  of  a  SOS,  plan  for  substantial  difficulties  and 
significant  time  and  resources. 

Lesson  5 


The  use  of  a  single  facility  with  an  environment  of  people,  processes,  and 
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Infrastructure  substantially  facilitates  the  integration  of  a  SOS  from  individual 
systems. 

Lesson  6 

The  process  for  SOS  integration  should  overtly  address  the  leadership  of  the 
integration  as  follows: 

an  on-site  acquisition  leader  empowered  for  the  integration  of  the  SOS  and 
an  on-site  leader  empowered  for  the  operational  community; 

supported  by  a  SOS  cadre  with  sufficient  resources  and  authority; 

supported  by  participants  who  manage,  develop,  and  operate  the 
constituent  systems  of  the  SOS. 

Lesson  7 

Certain  common  processes  and  common  infrastructure  in  the  integration 
environment  are  essential  to  manage  a  SOS  integration  successfully.  These  include  the 
following: 

an  Engineering  Board  with  responsibility  and  authority  for  identification  and 
resolution  of  SOS  issues  and  discrepancies,  including  the  assignment  of 
responsibility  for  correction; 

establishment  of  processes  (and  the  automated  means)  for  identification  of  SOS 
issues  and  discrepancies,  their  disposition,  tracking,  and  resolution,  under  the 
management  of  the  Engineering  Board; 

automated  support  for  the  tracking  and  tracing  of  SOS  operational  requirements; 

configuration  management  and  control  of  the  hardware  and  software  baselines  of 
the  systems  of  the  SOS  by  the  integration  leadership,  supported  with: 

automated  means  for  identifying  and  controlling  the  baselines  and 
subsequent  changes; 

a  formal  build,  verification,  and  re-integration  process  for  changes; 
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a  robust  communications  infrastructure  linking  the  teams  internal  to  the 
integration  environment  and  their  external  eounterparts; 

an  offiee  automation  environment  to  support  the  integration’s 
administrative  proeesses  as  well  as  to  support  interpersonal  proeessing  and 

eommunieations  for  the  partieipants. 

Lesson  8 

Certain  eommon  proeesses  and  infrastrueture  in  the  SOS  integration  environment 
promote  effeetiveness  and  effieieneies.  These  inelude; 

daily  planning  and  scheduling  of  resources  (people,  equipment,  faeilities) 
for  integration  events  with  eontingeney  plans  and  sehedules  readily 
available; 

timely  dissemination  of  information  pertinent  to  eaeh  integration  event, 
sueh  as  test  status,  equipment  availability,  and  results; 

daily  status  meetings,  with  results  immediately  available. 

Lesson  9 

Prototyping  a  SOS  can  provide  early  insight  into  operational  requirements  and 
into  the  SOS  systems  arehiteeture. 
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